我对一项任务有不好的感觉，子-子-子孩子应该获得“超级父代”的物理父代ID（外键）。
所以，这是当前的数据库/ orm结构
masterparent-> child1-> child2-> child3-> child4-> child5-> child6
总是oneToMany
这是一条很长的链。让我们以相反的顺序举一个更好的可读性示例：
nail-> getFingerPart（）-> getFinger（）-> getHand（）-> getHuman（）（并假设每个fingerPart可以有多个指甲；））
我的任务现在想在“钉子”，“ finger_parts”和“手指”中添加一列human_id（而不仅仅是拥有它的“手”）。
造成这种情况的主要原因是很多人为了从人类身上获得钉子而进行联接等等。 像human-> getNails（）这样的实体“快捷方式”看起来也很丑陋：foreach this-> getHands（）就像手... foreach hand-> getFingers（）...）
尽管我不认为这会是一个很大的性能问题（这不是每个毫秒都重要的高性能应用程序），但是，是的，这些联接很烦人，并且5-6个嵌套循环不会让你坠入爱河进入代码。
但是我不知道，只是感觉不对。
1。）我想您会在理论上级联删除时遇到问题。
2。）似乎您将弄乱结构，因为将不再有“真理之源”（手指说它属于人类1，手说它属于人类2）-但是，在我们这种特殊情况不会发生，因为您将无法更改“人”。但是，如果这是避免连接的常见行为，那么肯定会。
3。）在我们的例子中，您可以创建新的手，手指……在此更改之后需要设置人员的位置，因此我们需要更改很多代码（但我想这不会打动利益相关者）。
这里可能还会发生其他“冲突”吗？
是否有更好的方法（例如为此创建视图）？ 然后HumanView-> findAllBy（[“ human”：1]）;得到所有的钉子（但带有“真实的”可写实体-而不是只读视图实体）？
答案 0 :(得分：0)
您询问是否要在数据库模型中添加冗余。
这始终是可能的，它提供了优点和缺点。我最近没有使用过它，但是我当然记得在90年代使用这种慢速计算机并且在规范化数据库模型上查询花费了不可接受的时间。
最后，这是一项技术决定，要付出代价，利益相关者将不在乎，除非它直接影响底线。
PROS ：
缺点：
好吧，正如您所看到的，冗余有很多缺点。这些是我能想到的。
尽管如此，有时冗余是最好的解决方案，尤其是在硬件有限或海量数据的情况下。
如果您采用这种方式，请确保您了解所有弊端，并确保您和管理层愿意承担这些费用。