数据库结构问题：与祖父/父/子表有关系的表答案

【问题标题】：Database structure question: Table with a relationship to grand-parent/parent/child tables数据库结构问题：与祖父/父/子表有关系的表
【发布时间】：2011-06-22 20:50:44
【问题描述】：

我正在开发一个可追溯系统，用于记录多层次产品制造过程中的某些活动。祖父项由 2 个或 4 个父项组成，而父项又由 2 个子项组成。

在每个级别，在制造过程的不同点，对所有三种类型的项目进行泄漏测试 - 记录的信息将相同：泄漏率、通过或失败标志、时间戳等。

我是否要选择一个 LeakTests 表，它有一个通用的 FK 字段来保存与测试相关的项目的 ID，以及一个指示 FK 引用哪个表的指示器：

PK: LeakTestID, Int
FK: LeakTestItemID, Int
FK: LeakTestTypeID, Int
LeakageRate, Float
Result, Bit

我是否将每种类型的 FK 存储在不同的字段中？

PK: LeakTestID, Int
FK: ChildID, Int
FK: ParentID, Int
FK: GrandparentID, Int
LeakageRate, Float
Result, Bit

或者我是否选择 3 个泄漏测试表，每个级别的项目一个。

我可以看到每种方法的各种优点和缺点，并且我已经改变了好几次想法。

有什么想法吗？恐怕对这个系统的要求几乎没有定义，而我的一部分工作就是与业务和下游客户角力，以压住双方。但事实上，我无法确定数据将如何使用以及需求是否/如何可能发生变化。

澄清：我认为 g-parent/parent/child 位已经抛出了人们 - 3 层不是相同的层，它们是完全不同的，例如：

ATS:
PK: ATSID, Int
MeasurementA char()
MeasurementB char()
MeasurementC char()

SleevedPair:
PK: SleevedPairID, Int
MeasurementD char()
MeasurementE char()

SleevedItem:
PK: SleevedItemID
MeasurementG char()
MeasurementH char()
MeasurementI char()
MeasurementJ char()
MeasurementK char()

...碰巧每个对象都有一个或多个与之关联的泄漏测试。

【问题讨论】：

我认为要求缺乏明确性体现在问题中缺乏特异性。
好的，这将澄清问题。您说，“对所有三种类型的项目进行泄漏测试 - 针对每种类型记录的信息将是相同的：”适用于“组件”中所有项目的一项测试......或者它是一项测试程序集中的每个项目？
@Stephanie - 最初，SleevedItem 将进行泄漏测试。然后它将与另一个 SleevedItem 连接，创建一个 SleevedPair，该 SleevedPair 也将进行泄漏测试。然后将几个 SleevedPairs 安装到 ATS 中，并进行 5 次进一步的泄漏测试。在每种情况下，如果泄漏测试失败，该项目可能会被返工并再次进行泄漏测试。我希望这可以解决所有问题。

标签： sql sql-server database-design data-structures normalization

【解决方案1】：

每个都有优点，但我想我喜欢你的最后一个选项，为每个级别的对象使用泄漏表。这是我的推理：

您的第一个结构，它标识了 typeID 和 itemID 是不错的，但会导致比 3 个单独的表更大、更难使用的表。

第二个选项有时会有不必要的字段。对于祖父母级别的对象，您必须为父母和孩子记录空值，同样对于每个孩子，您都必须同时记录父母和祖父母，这可能是其他地方存在的信息。

虽然我不是专家，只是我的两分钱。

【讨论】：

我的想法类似。选项2是一团糟。第一个可以正常工作，但它是否正常化太远了？ 3 泄漏测试表选项很简单，但我可以将所有三个表组合起来……我应该这样吗？本质上，没关系——我认为 1 和 3 可以正常工作；我只是对最佳实践感到好奇。
您当然可以将它们组合起来，如果表很小且索引良好，那么性能可能大致相同。然而，真的有这样做的理由吗？如果您需要多个级别的结果，您始终可以连接 3 个表，但是当您只需要一个级别时，您只需使用一个较小的表。

【解决方案2】：

我的祖父母 (Steve) 是我父母 (Anne) 的父母。

ID     Name     ParentID
1      Steve
2      Anne       1
3      Steph      2
4      Amy        3
5      Sue        3

没有理由存储

ID     Name     ParentID  GparentID ChildID
1      Steve
2      Anne       1
3      Steph      2         1         4
4      Amy       ....

我可以通过检查我父母的父母来推导出我的祖父史蒂夫。同样，没有必要存储我的女儿是 Amy 和 Sue，因为我只需检查第一个表中的 parentID 列以获取我的 ID (ParentID = 3)。如果这些模棱两可的要求发生变化，这最终是灵活的。层次结构唯一不支持的是多个父母。除非每个节点最多可以有一个孩子，否则您只需翻转树并将 parentID 定义为 ChildID，然后每个孩子可以有多个父母。但每个父母只有一个孩子。如果您需要许多父母和许多孩子，则需要一个多对多映射表。

【讨论】：