【问题标题】:How can I reference an intersection table of a many-to-many relationship?如何引用多对多关系的交集表?
【发布时间】:2015-02-23 21:18:58
【问题描述】:

我正在创建一个处理处方的药房数据库。在设计数据库时,我考虑到医生可以在多个办公室工作,一个办公室可以住很多医生,所以我创建了以下多对多关系:

doctor:

| id | name | // more

office:

| id | name | address | // more

doctors_offices:

| doctor_id | office_id |

我遵循了在我的数据库教科书以及许多在线资源中看到的设计,但现在在尝试创建 prescription 表时遇到了一些困惑。在这张表中,我不仅想知道是哪个医生开的处方,还想知道在哪个位置。

我发现自己有几个选择:

  • doctors_offices 表添加一个 auto_increment 键,以便为每个博士/办公室配对提供唯一标识符
  • 向引用doctors_offices 的处方表添加一个复合外键。 (这可能吗?)
  • 向处方表添加两个外键。一个引用doctors,一个引用offices

这些选项中哪一个是最标准化的?我知道第三个可能是最少标准化的,因为它打开了我选择医生不属于的办公室的可能性,但我觉得很重要,因为它可能是一个常见的一些初学者数据库设计者的直觉。

【问题讨论】:

    标签: mysql database database-design normalization


    【解决方案1】:

    如果您将doctor_idlocation_id 与处方数据一起保存,会更加灵活。否则,如果医生在开出一些处方后搬到另一个办公室,您将遇到困难,除非您为医生在某个办公室的每个时间段重新输入。此外,当另一位医生在办公室并开处方时,您将无法正确描述这种情况,尽管他或她没有办公室分配。

    如果系统出于技术原因阻止他们插入数据,人们往往会变得聪明,您应该始终考虑这种例外情况,因为它们会发生。

    【讨论】:

    • 这很有意义。现在,它似乎是一把双刃剑。一方面,医生可以从任何办公室开处方,任何办公室都可以开任何医生的处方,这增加了灵活性。但是,如果医生从未访问过某个办公室,则会带来不准确的风险。但是我的应用程序无论如何都无法验证,对吧?如果他们进行了不正确的配对,那将是用户错误。
    • 根据我的经验,过多的限制会诱使用户输入错误的数据。有些信息必须尽快保存,大多数用户不了解您的数据库设计,最终通过输入错误数据绕过您的限制 - 尽可能不正确地保存它。
    • 好点。就处方方面而言,我不会关注我的交集表。当然,我仍然会保留它用于应用程序的其他方面。感谢您的洞察力!
    • 我一直在想这样一种情况:一名医生在多个办公室工作,但不允许他在给定(特定)办公室开药。虽然不确定这是一个现实的场景。假设是这样,我相信该信息将与 doctors_offices 相关,并且在关系中不使用其 PK,您会失去这种灵活性。
    • 然而,我同意@Œlrim 提出的观点,因为这个问题只与处方之间的关系->(医生、办公室)有关。处方本身不需要知道这些细节。如建议的那样,您可以将两个 ID(医生、办公室)存储在处方中,这将提供该处方所需的所有信息。然后 +1 :-)
    猜你喜欢
    • 2020-10-27
    • 1970-01-01
    • 2013-03-08
    • 2018-08-19
    • 2017-02-05
    • 1970-01-01
    相关资源
    最近更新 更多