我有两个表customer和partner，它们共享相同的属性（列名），但它们没有相同的关系。
关系如下：
只有客户有账户。
一个客户只能有一个合作伙伴。
客户有自己的职业。
伴侣有职业。
我的解决方案：
1
创建一个表（用户），其中包含具有外键的所有属性( customer_id )向相关客户推荐合作伙伴，因此：
客户是( account_id ) NOT NULL 以及( Customer_id ) NULL 合作伙伴是( account_id ) NULL 以及( Customer_id ) NOT NULL .
2
为customer和partner创建两个单独的表，并在partner表中放置一个外键以引用其相关的customer。
三
创建一个包含所有公共属性的基表，并在customer和partner表中添加一个外键来引用该表。
我想知道哪种方法是正确的。
2条答案
按热度按时间wn9m85ua1#
我没有看你提出的模型就建立了我的模型，最后我得到了一个非常接近你的2号模型的东西。唯一的区别是我将partnerid作为外键放在customer表中。你做了相反的事。在这里，这是一个选择的问题，合作伙伴是否有其他方式的客户？我看到的和你看到的相反。
对于您的问题1：您正试图将应用程序逻辑放在数据库模型中，我不会这么做。它很容易出现数据完整性问题（例如，最终用户的两个字段都==null！）。
对于您的no3：我理解您想要“隔离”公共字段，但是如果表user中的值无论如何都不会被重用，我看不出有什么意义。您将始终为每个客户和每个合作伙伴提供一条线。不如把它放在table上。只有当客户和合作伙伴不是同一个人时，这才有效。
tpxzln5u2#
我是说你误解了什么。您强制尝试将不同实体（客户、合作伙伴）的属性组合在一起。您可能想要或应该做的是规范化数据(所以你已经得到了一些关键词供进一步研究）。
客户不是合作伙伴，也不是实体。如果您想将所有内容放入一个表中，如解决方案1中所示，那么首先“user”这个名称是有误导性的。其次，必须插入一个指定类型的属性（例如entitytype（customer，partner）并引用一个单独的表）。你的建议是否为空是非常容易出错的，没有人会理解（3个月后你也不会理解）。如果业务逻辑发生了变化，以致于合作伙伴获得了登录，那么您就已经遇到了问题。
快乐学习……”教一个人钓鱼，你要喂他一辈子”