mysql - 将子子项中的外键添加到 "super parent"- 是否有更好的方法如 View ？

Question

我对一项任务有一些不好的感觉，子子子子应该将物理父 ID(外键)传递给“ super 父”。

所以，这是当前的数据库/orm结构

masterparent->child1->child2->child3->child4->child5->child6

总是一对多

所以这是一个很长的链。让我们以相反的顺序举一个更易读的例子:

nail->getFingerPart()->getFinger()->getHand()->getHuman()(并假设每个 fingerPart 可以有多个指甲；))

我的任务现在想要将 human_id 列添加到“nails”、“finger_parts”和“fingers”(而不仅仅是“hand”)。

造成这种情况的主要原因是从人类身上获取所有指甲的许多连接等等。像 human->getNails() 这样的实体“快捷方式”看起来也很丑陋:foreach this->getHands() as hand ... foreach hand->getFingers() ...)

虽然我不认为这会是一个大的性能问题(它不是每毫秒都很重要的高性能应用程序)，但是是的，这些连接很烦人而且 5-6 嵌套循环不会让你坠入爱河进入代码。

但我不知道，就是感觉不对。

1.) 我猜你会在 Doctrine 中遇到级联删除的问题。

2.) 看起来你会弄乱结构，因为不再有“真相来源”(手指说它属于人类 1，手说它属于人类 2)——但是好吧，在我们的特殊情况不会发生这种情况，因为您将无法更改“人”。但是，如果这成为避免连接的常见行为，那肯定会。

3.) 在我们的案例中，您可以创建新的手、手指……在此更改后我们需要在其中设置人体，因此我们需要更改大量代码(但我想，这不会给利益相关者留下深刻印象)。

还有其他可能发生的“冲突”吗？

有没有更好的方法比如为此创建 View ？然后 HumanView->findAllBy(["human": 1]);获得所有钉子(但使用“真正的”可写实体 - 而不是只读 View )？

Answer 1

您询问是否要为您的数据库模型添加冗余。

这总是可能的，并且它提供了优点和缺点。我最近没用过它，但我当然记得在 90 年代用过它，当时我们的机器速度很慢，而且查询在规范化数据库模型上花费的时间令人无法接受。

归根结底，这是一项有成本的技术决策，利益相关者不会关心，除非它直接影响底线。

优点:

• 高速查询。
• 简单且更短的查询，代码更少。更易于阅读和书写。

缺点:

• 冗余。并且有很多关于它的文章。
• 现在每个数据修改都需要在一个事务上执行，因为它总是包含多个更新/删除。
• 即使是简单的数据修改也需要大量代码。
• 所有开发者都需要理解并以正确的方式做到这一点。
• 哦... 一个使用该数据库的新应用程序出现了，新的团队将对其进行更改。他们知道如何做对吗？你信任他们吗？
• 也许您需要编写夜间流程来检查/修复冗余。

好吧，如您所见，冗余有很多缺点。这些是我能想到的。

尽管如此，有时冗余是最好的解决方案，特别是当您的硬件有限或数据量很大时。

如果您采用这种方式，请确保您了解所有缺点，并且您和管理层愿意承担成本。