我正在开发一个可追溯系统，记录多层物品制造过程中的某些活动。祖父项目由2或4个父项组成，而父项又包含2个子项。
在每个级别，在制造过程的不同阶段，对所有三种类型的项目进行泄漏测试 - 针对每种项目记录的信息将是相同的：泄漏率，通过或失败标志，时间戳等。
所以我选择一个 LeakTests 表，使用通用FK字段来保存测试所涉及的项目的ID，以及显示FK所指的表格的指示符： / p>
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 x泄漏测试表，每个级别的项目一个。
我可以看到每种优点和缺点，我已经多次改变主意了。
有什么想法？我担心这个系统的要求几乎没有定义，我的部分工作就是与业务部门和下游客户进行斗争，将双方都打倒。但事实上，我无法确定数据将如何使用以及需求是否/如何变化。
澄清：我认为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()
...恰好每个对象都有一个或多个与之关联的泄漏测试。
答案 0 :(得分：1)
每个人都有各自的优势，但我认为我喜欢你的最后一个选择，为每个级别的对象使用泄漏表。这是我的理由：
你的第一个结构，它标识了一个typeID和itemID是不错的，但是会产生一个比3个单独的更大，更难使用的表。
第二种选择有时候会有不必要的字段。对于永远祖父级别的对象，你必须记录父和子的空值，同样对于你必须记录父和祖父母的每个孩子，这可能是在其他地方存在的信息。
我不是专家，只是我的两分钱。
答案 1 :(得分：0)
我的祖父母（史蒂夫）是我父母的（安妮）父母。
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，然后每个子节点就可以有多个父节点。但每个父母只有一个孩子。如果你需要很多父母和很多孩子，你需要一个多对多的映射表。