我对一个任务有一些不好的感觉,在这个任务中,子孩子应该得到一个“超级父母”的物理父母ids (外键)。
因此,下面是当前的数据库/orm结构
masterparent->child1->child2->child3->child4->child5->child6
always oneToMany
所以这是一个相当长的链条。让我们来看一个可读性更好的例子,顺序颠倒:
nail->getFingerPart()->getFinger()->getHand()->getHuman() (并假设每个fingerPart可以有多个nails;)
我的任务现在想要向"nails“、"finger_parts”和"fingers“添加一个列human_id (而不仅仅是"hand”)。
这样做的主要原因是为了从人类那里获取所有钉子而进行的大量连接,等等。像human->getNails()这样的实体“快捷方式”看起来也很丑陋: foreach this->getHands()就像hand ...foreach hand->getFingers() ...)
虽然我不认为这会是一个大的性能问题(这不是一个高性能的应用程序,因为每个ms都很重要),但是的,这些连接是恼人的,5-6个嵌套循环不会让你爱上代码。
但我不知道,只是感觉不对劲。
1.)我猜你会遇到级联删除的问题。
2.)看起来你会弄乱结构,因为将不再有“真理的来源”(手指说它属于人类1,手说它属于人类2) -但在我们的特殊情况下,这种情况不会发生,因为你不能改变“人类”。但是,如果这获得了一个共同的行为来避免连接,那么它肯定会。
3.)在我们的例子中,你可以创建新的手,手指,...在此更改后,我们需要设置人员,因此我们需要更改相当多的代码(但我猜,这不会给利益相关者留下深刻印象)。
这里还有其他可能发生的“冲突”吗?
有没有更好的方法来创建一个视图呢?然后HumanView->findAllBy("human":1);来获取所有的钉子(但使用“真正的”可写实体-而不是只读的视图实体)?
发布于 2019-06-18 21:51:39
您询问有关将redundancy添加到数据库模型的问题。
这始终是可能的,而且它提供了好处和缺点。我最近没有用过它,但我肯定记得在90年代做过它,当时我们的机器速度很慢,查询在规范化的数据库模型上花费了不可接受的时间。
归根结底,这是一个有成本的技术决策,利益相关者不会关心,除非它直接影响底线。
PROS
CONS
嗯,正如你所看到的,冗余有很多缺点。这些都是我一想到就能想到的。
尽管如此,有时冗余是最好的解决方案,特别是在硬件有限或数据量巨大的情况下。
如果你这样做,请确保你了解所有的缺点,并确保你和管理层愿意处理成本。
https://stackoverflow.com/questions/56649845
复制相似问题