【问题标题】:Doctors, Patients and Contact information for both医生、患者和两者的联系信息
【发布时间】:2016-11-20 16:39:13
【问题描述】:

我有两张桌子DOCTORSPATIENTS。我希望医生和患者都有不固定的联系信息(例如电话号码、地址等)。例如,我们可以为医生或患者添加多部电话。

我考虑过创建一个单独的表,例如PHONES 带有字段 phoneID、电话号码和指向联系人的外键,如下所示:

电话

phoneID [pk]
number
contactID [fk]

医生

docID [pk]
fname
sname
specialization
.
.
.

患者

patID [pk]
fname
sname
.
.
.

第一个问题来自patIDdocID 可能(并且最终)具有相同值的事实。因此,将电话与一个且只有一个人关联变得更加困难。

到目前为止,我已经想到了三种可能的解决方案:

  1. 为医生和患者提供自定义格式的主键。例如,医生可能有“d00001”、“d00002”等形式的 id,而患者 id 可能有“p00001”、“p00002”等形式。我担心这可能会使事情变得不必要地复杂化。

  2. 另一种解决方案是将医生和患者放在一个表中,并通过使用另一个字段来定义他们是医生还是患者。

  3. 为医生和患者创建单独的PHONE 表,但这更加笨拙。

不知何故,我认为这两种方法都不是最好的。有什么建议吗?

【问题讨论】:

    标签: sql sql-server


    【解决方案1】:

    你可以介绍一个PERSON-table。这是1:1,与您的医生和患者有关(以后可能与员工、供应商、机构等有关)。让联系人与此人员表相关。

    应用程序代码可以很容易地通过继承对此进行建模...

    在您的人员表中,您保留了一些一般信息,例如DisplayNamePersonType(参考人员类型表,其中包含DoctorPatient 和...等条目)。

    保持这张桌子苗条...

    如果您必须从自己的想法中选择,我更喜欢第二种。将它们放在一个表中并用类型列标记它们。避免说话键...

    【讨论】:

    • 谢谢,这个答案肯定解决了问题并有助于扩展我的 Web 应用程序,因为 People 表不仅可以用于保留显示名称,还可以用于显示图片。我也在考虑下面“dbenham”所说的内容,因为例如儿童患者有必要分享他们父母的电话号码和地址。感谢您的帮助!
    • @Paradoxo44 我很高兴,你喜欢它!您可能想阅读我对 dbenham 回答的评论...
    • 您的建议是这样的吗? ![model.jpg](postimg.org/image/ux0bcpgm7)
    • @Paradoxo44 是的,很像这样...tblPersons 与专业化tblDoctorstblPatients 之间的关系应该是1:1,因为医生 这个人和一个病人这个人。一个人可能是一名医生一名患者。把它想象成一个人的角色......
    • 在这种情况下,tblPersons 中的 refID 可以指代具有相同 ID 的两个人(例如 docID = 5 和 patID = 5),我必须从我的应用程序代码中进行检查。我想这就是为什么我需要在 Persons 表中声明的 PersonType。或者我错过了什么。
    【解决方案2】:

    你对关系的看法是错误的。

    人与电话号码之间存在多对多关系。

    一个人可以有许多不同的电话号码(家庭、工作、手机等)

    一个电话号码可以关联很多人(丈夫、妻子、孩子、同事……)

    我不明白为什么您需要一个以电话号码作为主键或备用键的主实体。

    我会使用 5 张桌子:

    Doctor PK=DoctorID
    
    Patient PK=PatientID
    
    PhoneType PK=PhoneTypeCode
    
    DoctorPhone PK=DoctorID,PhoneTypeCode,PhoneNum  
      FK1=Doctor.DoctorID  
      FK2=PhoneType.PhoneTypeCode
    
    PatientPhone PK=PatientID,PhoneTypeCode,PhoneNum
      FK1=Patient.PatientID
      FK2=PhoneType.PhoneTypeCode
    

    您可能会考虑使用不同的 DoctorPhoneType 和 PatientPhoneType 表,因为这两类人的电话角色可能不同。

    【讨论】:

    • 您说的很对,患者可能包括家人,所以电话和地址将被共享。我开始设计我的数据库时认为我绝对必须避免对相同的事情使用重复的表:电话和地址。但你说得很对。感谢您的意见!
    • 老实说,我认为这种设计走得太远了......共享地址或联系信息会让您陷入最深的麻烦,例如,如果 - 最年长的孩子有自己的电话号码。更改共享号码,将其传播给所有人。所以你必须定义一个数字的所有者,并引入一堆额外的逻辑。对我来说更好的是继承级联:如果孩子没有电话号码,我们查看关系,看看近亲是否有电话。我们这样做,直到我们找到一个家庭电话号码。如果爸爸妈妈有自己的电话号码,我们会找到其中一个...
    • @Shnugo - 什么共享联系信息?每个病人或医生都有他/她自己的一组不共享的电话号码。
    • 你的一个电话号码可以关联很多人让我觉得,你的m:n 方法会将一个信息绑定到很多人。一个地址给全家,一个电话号码给母亲和她的孩子......但是如果你改变这个(离婚,父亲变平,哦,我有一个新地址!)每个人都会得到这个新地址。这可能是一个很好的方法,但在普通的医患软件中,这是非常复杂的,远远超出了工人的维护能力……你不这么认为吗?
    • @Shnugo - 看来我们仍在谈论交叉目的。是的,我说过一个电话号码可以适用于很多人,而我的模型允许将同一个号码分配给任意数量的人。但我没有将电话号码建模为主要实体。在我的模型中,每个患者的电话号码必须独立维护。更改父亲的电话号码对家庭中的其他人没有影响。再看看我的模型。请注意,PhoneTypeCode 代表“家庭”、“工作”等内容。不是电话号码。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2020-05-09
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多