当父母&子表都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)，但它有点像循环引用。使用引用表来定义约束条件更好吗？
有几种方法，您需要的方法取决于您的业务需求。
首先，一个子记录可以有多个父记录吗？例如，您可能正在建模一个组织结构，其中一名员工可以有两名主管。如果这是真的，那么您有一个一对多的关系，并且需要一个单独的表来运行这个模型。
如果保证每个子项只有一个父项(但每个父项可能都有一个父级(构建层次结构)，则可以将其建模为一个表。表结构将包括主键(比如UserID)，然后是父级的可为null的列(比如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的性能很慢，您可以控制层次结构的构建方式(最好只通过导入数据)，以及它是否很少发生变化(你不想每分钟都重建层次结构，但可以每天导入一次。这可以大大加快查询整个层次结构的速度，但如果父子关系是通过应用程序不断创建和更改的，则不建议这样做。