在我们有客户，供应商和＆amp;所有具有共同属性的分支，例如地址，这是一个更好的解决方案，为什么？
解决方案1：
客户表
供应商表
分支表
包含CustomerID，VendorID，BranchID的可空外键的地址表
解决方案2：
实体表
包含EntityID的客户表
包含EntityID的供应商表
包含EntityID的分支表
包含EntityID的地址表和EntityType标志为“C”，“V”或“B”
解决方案3（由AJC建议）：
客户表
供应商表
分支表
地址表
客户与地址之间的CustomerAddress外部参照表
供应商和地址之间的VendorAddress xref表
分支和地址之间的BranchAddress外部参照表
解决方案4（由9000建议）
客户表
供应商表
分支表
FK到客户的CustomerAddress
FK与供应商的VendorAddress
BranchAddress with FK to Branch
vwAddress UNION ALLs上述每个地址表，并包含一个类型标志（'B'，'C'，'V'）
注意：
每个客户，供应商或分支机构可能有多个地址，但至少应有一个。
如果“实体”既是客户又是供应商，则每个角色可以有单独的地址。
想知道客户是否也是供应商。
答案 0 :(得分：3)
（这基本上是@AJC所说的，只是解释过。）
解决方案1可能允许为最多三个不同类型的实体分配相同的地址。除非后者完全是您的意图，否则请避免使用此解决方案。
解决方案2允许为客户等分配“B”类型地址。可能这也不是您想要的。
据我了解您的意图，您需要能够为实体分配多个地址，但不能相反。
为每个实体类型创建一个地址表：CustomerAddress，其中FK引用Customer，VendorAddress，FK引用Vendor等。除了严格的引用完整性和不可能分配这是一个不正确类型的地址，这使您能够扩展每种类型的地址，并使用仅对其有意义的额外字段。
要更轻松地查询所有地址，您可以创建一个视图Address，其中包含公共字段和类型标记（'B'，'C'，'V'）以查看哪种地址是这个。
答案 1 :(得分：2)
C）以上都不是。
正确的方法是分别使用地址表和CustomerAddress，VendorAddress和BranchAddress将每个C V B实体与一个或多个地址连接起来。
对于一对一的属性，显然不需要额外的表，只需将Id添加到主表（AddressId）......