将子项中的外键添加到“超级父项”-有没有更好的方法,例如视图?

时间:2019-06-18 13:04:07

标签: mysql database-design doctrine

我对一项任务有不好的感觉,子-子-子孩子应该获得“超级父代”的物理父代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]);得到所有的钉子(但带有“真实的”可写实体-而不是只读视图实体)?

1 个答案:

答案 0 :(得分:0)

您询问是否要在数据库模型中添加冗余

这始终是可能的,它提供了优点和缺点。我最近没有使用过它,但是我当然记得在90年代使用这种慢速计算机并且在规范化数据库模型上查询花费了不可接受的时间。

最后,这是一项技术决定,要付出代价,利益相关者将不在乎,除非它直接影响底线。

PROS

  • 高速查询。
  • 简单而短的查询,只需更少的代码。易于阅读和编写。

缺点

  • 冗余。并且有很多关于它的文章。
  • 每个数据修改现在都需要在事务上执行,因为它始终包含多个更新/删除。
  • 很多代码,甚至用于简单的数据修改。
  • 所有开发人员都需要了解并以正确的方式进行操作。
  • 哦...一个使用数据库的新应用程序进来了,它将由新团队进行更改。他们知道该怎么做吗?你相信他们吗?
  • 也许您需要编写每晚检查/修复冗余的过程。

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

尽管如此,有时冗余是最好的解决方案,尤其是在硬件有限或海量数据的情况下。

如果您采用这种方式,请确保您了解所有弊端,并确保您和管理层愿意承担这些费用。