我有一个正在为其设计的数据库。我有制造商和经销商在不同的表上，其中包含几乎相同的信息，几乎没有例外。两个组都有一对多联系人需要连接到他们。我创建了一个联系人表来保存联系信息，一个！
我需要第二个联系表吗？我正在努力使其尽可能干燥。那看起来怎么样？先感谢您
I have a database I'm working on the design for. I have manufacturers and I have distributors on separate tables containing practically the same information with few exceptions. Both groups have one-many contacts that need to be connected to them. I created a contact table to hold contact information, one!
Do I need a second contact table? I'm trying to make this as DRY as possible. How would that look? Thank you in advance
发布评论
评论（1）
也许是当事人角色模式的情况？
制造商和分销商是各方扮演的角色。联系方式适用于缔约方，而不适用于他们所扮演的角色。因此，您将拥有：Party的表ContactMethod（或类似）的表，这将解决对两个
的需求>联系方式表。如何对角色进行建模将取决于更广泛的需求。规范模型将具有：Role的单个超类型（注：顺便说一句，这也允许一方扮演制造商和分销商的角色 - 这可能相关也可能不相关）。
在关系表中实现子类型层次结构有 3 种“标准”模式：
如果您没有任何特定于角色的关系，则适用 (1)。 （但是我怀疑这不太可能；可能有一些与分销商相关的信息不适用于制造商，反之亦然）。
(2) 表示来自参与方的多个关系（即每个角色子类型都有一个关系）。
(3) 避免了上述两者，但意味着从一方导航到其角色的额外加入。
就像我说的，选择取决于更广泛的要求。
嗯。
Maybe a case for the party-role pattern?
ManufacturerandDistributorare roles played by Parties. Contacts apply to Parties, not the role(s) they play. So you'd have:PartyContactMethod(or similar)which would resolve the need for two
Contacttables. How you model the roles side will depend on wider requirements. The canonical model would have:Role(Note: as an aside, this also allows a Party to play both manufacturer and distributor roles - which may or may not be relevant).
There are 3 'standard' patterns for implementing a subtype hierarchy in relational tables:
(1) would apply if you don't have any role-specific relationships. (However I suspect that's unlikely; there's probably information related to Distributors that doesn't apply to Manufacturers and vice-versa).
(2) means multiple relationships from Party (i.e. one to each role subtype).
(3) avoids both above but means an extra join in navigating from Party to its role(s).
Like I say, choice depends on wider reqs.
hth.