【问题标题】:Link-table column that must be able to contain both FOREIGN KEY and a special value必须能够同时包含 FOREIGN KEY 和特殊值的链接表列
【发布时间】:2013-04-20 14:30:26
【问题描述】:

我需要在数据库中表示以下信息(简化):

  1. 一套“账单”。 (在表中Bills
  2. 一组“代表”。 (在表中MPs
  3. 每个法案的作者。
    • 如果只有“代表”可以是作者,这将是一个简单的链接表,其中包含指向 BillsMPs 的外键。
    • 还有一个(只有一个)其他“实体”也可以是账单的作者,因此:
      • 我可以将 NULL 重新定义为“实体”,但这很难看。
      • 我可以简单地忘记 FOREIGN KEY 约束,但这更难看。

根据数据库理论,表示此信息的正确方式是什么?

有一个表linktable_authors 链接BillsMPs 是否适合“代表”编写的“票据”,而另一个表authored_by_The_Entity 仅用于“实体”编写的“票据” (如果我死了,确定以后不会有其他实体出现)?

奖金问题: 如果还有一个表“Other_Entities”,并且“Other_Entities”和“Representatives”都可以是“Bills”的作者怎么办?

【问题讨论】:

    标签: sql database database-design relational-database database-schema


    【解决方案1】:

    使用 PK AuthorID 定义实体 Authors。将子实体 RepresentativesOtherEntities 的 PK 设为 AuthorID,以创建类型关系。为 Authors 添加属性 AuthorType 以区分子类型冲突。将作者共有的所有属性放在 Authors 实体中。

    顺便说一句:NULL 从不表示“其他已知值”。在其他一些选择中,它可以明智地表示“不适用”或“尚不知道”,但给它“一些其他已知值”的语义是设计不佳的明确标志。

    【讨论】:

    • 我想这是在回答我的“额外问题”,但对于原始问题(只有一位可能的作者不是代表)来说,这不是矫枉过正吗?
    • 一旦你提出了允许奖金情况的业务规则的存在,你就完全没有理由只考虑更简单的情况。除非有压倒性的理由不这样做,否则总是为更一般的情况设计;因为你会比你想象的更早需要它。
    • 我同意,但出于教育目的,我对原始问题的解决方案非常感兴趣。
    • 但作者可以是代表或其他作者。第一个问题的正确解决方案是不要假设只有一个 OtherAuthor。
    • 我明白了。我会等一下,可能会选择这个作为接受的答案。另一方面,您能否补充一下我在修改后的问题中建议的两表解决方案是否存在任何明显的问题?
    猜你喜欢
    • 2018-05-22
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多