数据库中的三角关系

Question

我在找出一些数据库表之间的关系时遇到了问题。这种情况的场景是一个b2b buissnes。

我有三张桌子：

• 用户
• 公司
• 分销商。

A公司有多个用户(1对多)公司有多个分销商(多对多)分销商有多家公司(多对多)用户有1家公司(多到1)

现在我被困在下一步了。

我在系统中构建了一些角色和权限。

用户可以是：-经销商-A公司(经理)-用户

在完美的场景中，用户可以是经销商，也可以是公司。我怎样才能在数据库中做到这一点。我想出了一个解决办法，但这不是最好的解决办法。这将使用户将处于与公司和经销商的OneToMany关系。关系可以为空，当用户是公司时，将设置与公司的关系。如果用户是分发服务器，则将设置与分发服务器的关系，公司关系将为空。

我认为这不是最好的解决办法，但我想不出更好的解决办法。

我如何使用户可以是一个经销商或公司，而不将关系设置为0。

Answer 1

用于用户关系

的替代方案

理论上有哪些选择：

1. 您有一个类User，它与Company关联，另一个关联到Distributor。在这两个关联之间也有一个约束，即只有一个可以在给定的时刻处于活动状态。结果:关联可能会随着时间的推移而改变，用户一旦被分配到公司，稍后就会被分配给经销商。
2. 您有一个通用类User，它有两个专门化:与Company不关联的CompanyUser和与distributor关联的DistributorUser。结果:虽然公司用户可能会随着时间的推移而更改公司，但他/她可能不会更改为分发服务器(需要创建不同的用户)。

对替代

的选择

在你看来，哪种模式最准确？公司用户和分销商用户之间的其他区别是什么，可以证明专业化是合理的？

我手头没有所有的卡片，但直觉地说，我会选择1，这将实现与您所描述的完全一样。

方法2将实现(也)如您所描述的(使用单继承表模式)或使用2个表(假设用户是抽象的并使用具体表继承模式，但这两个表可能看起来非常相似)，或者使用3个表(使用类表继承)和两个需要大量sql联接的附加关系。

现在，看看这些其他的替代方案，除非公司和经销商的用户会有很大的不同，在我看来，额外的表似乎是过头了，我仍然坚持您最初的方法，这在我看来是一个非常好的选择。

公司/分销商方面的其他替代方案?

但是，还有一个值得研究的问题:您确定distributor和company不是抽象LegalEntity的两个专门化吗？

在这种情况下，您可以考虑简化用户端的事情，只在他/她所属的user和LegalEntity之间建立一个关系。然后，您将将法律实体、分发服务器和公司管理为类继承表方案的表，该表方案实现了类之间的继承方案。

也许最后一种选择是过分的，但根据分发服务器和公司之间的相似之处，您可以通过代码中更多的一致性和更少的冗余来弥补额外的复杂性。