0

当父表和子表都对同一个表进行 FK 时，最佳做法是什么？

Parent > Child(ren) 

CommonAttributes: Sex, Age, Height, Weight

直接引用公用表是不是更好：

CommonAttributes > Parent(s) > Child(ren)

&

CommonAttributes > Child(ren)

或使用参考表：

RefTable: CommonAttributes_Id, Parent_Id(null), Child_Id(null)

我认为第一种方法工作正常（关于 EF），但它有点循环引用。使用参考表来定义约束是否更好？

4

1 回答 1

2

有几种方法可以解决此问题，您需要的方法取决于您的业务需求。

首先，一个子记录可以有多个父级吗？例如，您可能正在建模一个员工可以有两个主管的组织结构。如果这是真的，那么你有一个一对多的关系，并且需要一个单独的表来让这个模型工作。

如果您保证每个孩子只有一个父级（但每个父级可能有一个父级（构建层次结构），那么您可以对这是一个表进行建模。表结构将包括主键，比如 UserID，然后是一个可为空的列为父级，例如 ParentUserID。然后您可以为同一个表中的字段创建外键。

ALTER TABLE dbo.Mytable  ADD CONSTRAINT FK_Mytable _UserPArent FOREIGN KEY (ParentUserD)      REFERENCESdbo.Mytable (UserID)

如果要在查询中构建层次结构，则使用递归 CTE 来获取它。请参阅此处的示例： https ://msdn.microsoft.com/en-us/library/ms186243.aspx

另一次您可能想要为子父关系构建一个单独的表是，如果主表中只有一小部分记录将具有父子关系。例如，假设您有一个存储销售代表和客户的人员表。只有销售代表才会有父子关系。因此，您需要一个单独的 SalesRepHierarchy 表来存储它，这将使查询更加直接。

虽然通常您希望在递归 CTE 中创建层次结构，但在某些特殊情况下，预先计算层次结构可能会更快。如果经常查询层次结构，CTE 性能很慢，并且您可以控制层次结构的构建方式（最好仅通过数据导入）以及它很少更改（您不希望重建层次结构），则这是正确的每分钟一次，但可以容纳一天一次的导入。这样可以大大加快速度，并且可以简单地查询整个层次结构，但如果通过应用程序不断创建和更改父子关系，则不建议这样做。

于 2017-01-18T16:39:56.230 回答