【问题标题】:subtype or separate tables?子类型或单独的表?
【发布时间】:2013-12-18 18:06:38
【问题描述】:

我有以下实体:书籍、作者和商店。

它们每个都可以有一个 cmets 部分。我应该将 cmets 存储在单独的表中还是有子类型/超类型设计?如果我使用单独的表格在技术上是错误的吗?因为无论哪种方式,它可能需要相同数量的工作,或者如果任何子类型的超类型层次结构发生变化,则子类型设计可能需要更多工作。

【问题讨论】:

    标签: relational-database


    【解决方案1】:

    超类型和子类型解决了“这些东西不完全相同,但也没有完全不同”的问题。

    超类型/子类型设计要求一些属性存储在超类型中,而另一些属性存储在子类型中。现实世界中每个事物的属性都在两个表之间进行拆分。

    您如何决定如何拆分属性? 所有子类型共有的属性“向上”移动到超类型中。所以如果你从公司和个人开始,他们并不完全一样,因为

    • 一个是个体,另一个是(概念上)一群个体,
    • 一个可以有孩子,另一个不能,
    • 一个可以结婚,另一个不能

    等等。

    它们并没有完全不同,因为

    • 两者都可以有多个地址、电话号码、电子邮件地址、网站等,
    • 双方都可以与其他公司签订合同,
    • 两者都可以与其他人签订合同,
    • 两者都需要提交纳税申报表

    等等。

    两者共有的属性(至少是法定名称)冒泡“向上”进入超类型。

    但是,在您的情况下,尚不清楚书籍、作者和商店如何适合该分析。很明显,它们并不完全相同。但它们完全不同吗?我想是的。

    如果您谈论的是关于书籍、人物和商店的网站帖子之类的内容,那就另当别论了。 answer to a similar SO question 包含代码。

    【讨论】:

    • cmets 适用于书籍、作者和商店(cmets 的属性在 3 个实体之间是相同的)。即使评论属性相同(每种评论类型的表等),为每个实体拥有 3 个单独的评论表在技术上是否错误?是否会因为您为每个评论类型表重复评论属性而被视为规范化?
    • @firebird:技术上是错误的?也许。 (但它与规范化无关。)具有重叠含义的表违反了正交设计原则。见dbdebunk.com/page/page/622331.htm
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2021-12-24
    • 2019-08-26
    • 1970-01-01
    • 1970-01-01
    • 2020-09-16
    相关资源
    最近更新 更多