我被要求在我们的数据库中添加一个新的地址簿表(SQL Server 2012).

为了简化数据库的相关部分,有三个表,每个表以一对多的方式相互链接：公司(有很多)产品(有很多)项目,并且想法是一个或多个地址将能够存在在任何一个级别.我们的想法是,在前端系统中,用户将能够查看和选择他们指定的项目的特定地址以及与其父产品和公司相关的更多通用地址.
现在的问题是如何在数据库中对此进行建模.

到目前为止,我已经想到了两个可能的想法,所以想知道是否有人有类似的关系模型本身以及如何实现它？

想法一：
新地址表还包含三个字段：companyID,productID和projectID.这些字段将与相关表相关,并且可以为空,以表示公司和产品级地址.例如companyID 2,productID 1,projectID NULL是产品级地址.
我的问题是我将关系信息存储在表中,因此如果项目被更改为与不同的产品相关,则此表中的数据将不正确.除了我感兴趣的关卡之外,我可能只剩下NULL,但这会让父地址变得更难获得

想法二：
在地址表上有一个typeID和一个genericID. genericID可以包含Company,Product和Project表中的ID,typeID确定它来自哪个表.我有点困惑如何设置必要的约束来做到这一点,并想知道这是否会在将来处理棘手

非常感谢,

最佳答案 我建议使用Idea one并防止Idea 2.

第二个想法被称为Polymorphic Association反模式
目标：参考多个父母
产生的副作用：使用两用外键将违反第一范式(原子问题),失去参照完整性
解决方案：简化关系

可以通过两种方式获得关系的简化：

>拥有多个可归零的伪造键(想法编号1)：那将是
如果表(产品,项目,…)使用简单和适用
这种关系是有限的. (想想他们长大的时候)
>另一种更通用的解决方案是使用继承.定义一个
新实体作为(产品,项目,……)的基表来满足
寻址.可能将组织单位命名为更合理.此organization_unit表的主键将是(product,project,…)的主键.其他集合(如Address,Image,Contract …表)将与此基表有关系.