首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >将子孩子中的外键添加到“超级父级”中--有没有像视图这样更好的方式?

将子孩子中的外键添加到“超级父级”中--有没有像视图这样更好的方式?
EN

Stack Overflow用户
提问于 2019-06-18 21:04:07
回答 1查看 15关注 0票数 1

我对一个任务有一些不好的感觉,在这个任务中,子孩子应该得到一个“超级父母”的物理父母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);来获取所有的钉子(但使用“真正的”可写实体-而不是只读的视图实体)?

EN

回答 1

Stack Overflow用户

发布于 2019-06-18 21:51:39

您询问有关将redundancy添加到数据库模型的问题。

这始终是可能的,而且它提供了好处和缺点。我最近没有用过它,但我肯定记得在90年代做过它,当时我们的机器速度很慢,查询在规范化的数据库模型上花费了不可接受的时间。

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

PROS

  • 高速queries.
  • Simple和更短的查询,用更少的代码。更易于阅读和写入。

CONS

  • 冗余。现在每一次数据修改都需要在transaction,上执行,因为它总是包含多个updates/deletes.
  • A的代码,即使对于简单的数据,modification.
  • All开发人员也需要理解并以正确的方式来做这件事。
  • 哦...一个使用数据库的新应用程序出现了,它是一个新的团队,他们将对它进行更改。他们知道该怎么做吗?你信任他们吗?
  • 也许你需要编写每晚的进程来检查/修复冗余。

嗯,正如你所看到的,冗余有很多缺点。这些都是我一想到就能想到的。

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

如果你这样做,请确保你了解所有的缺点,并确保你和管理层愿意处理成本。

票数 0
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/56649845

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档