SQL泛化/专业化，数据冗余

Question

我有三个表：动作，消息，喜欢。它定义了继承，消息和喜欢是动作的孩子（专业化）。

Message和Like都有列userId和createdAt。这些当然应该移到parrent表Action并从Message和Likes中删除。但是只有一种情况我需要从数据库中选择消息和喜欢，在其他情况下我只选择其中一个消息或喜欢。

可以在child和parrent表中复制userId和createdAt吗？它花费了磁盘空间但节省了一个连接 - 我必须加入消息，喜欢每次我需要userId和createdAt时的动作。什么，我需要更改我当前的代码...

你会建议什么？

Answer 1

在我看来，这是一个过早优化的例子（或者如果你愿意的话，过早的非规范化）。您猜测连接开销会导致严重问题，因此您猜测复制userId和依赖表中的createdAt列将显着提高性能。

我建议您不要复制列，直到您知道存在真正的问题。我对墙上的性能优化进行了一些观察，以提醒自己在类似情况下应该做些什么：

1. 它没有破坏直到它破裂。
2. 你无法改善你未测量的东西。
3. 节目在最恶劣的地方花费了大量的时间。
4. 让它运行。让它运行正确。让它快速运行。
   • 优化实际上是你应该做的最后一件事。
   • 更快地做错事并没有什么好处。

还有一些关于非规范化的评论：

1. 您无法对未规范化的内容进行非规范化。
2. 如果大多数开发人员从屏幕后面跳出来，像女妖一样尖叫，并且在他们头上砸了一根棒球棒，那么大多数开发人员都不会知道第三普通形式。
3. 建议将非规范化作为数据库性能问题的灵丹妙药。问题是那些推荐非规范化的人往往从未规范过任何事情。
4. “出于性能原因的非规范化”是草率的“做我们一直以来所做的”思考的借口，特别是当这种非规范化被载入设计时。

根据我的经验，在编写代码之前，我无法确定性能问题的发生位置。问题总是出现在我永远不会想到的地方。因此，我发现我最好的选择始终是编写最简单，最清晰的代码，尽可能简单地设计数据库，遵循规范化规则，尽我所能，然后处理什么出现了。可能仍然存在需要注意的性能问题（但是，令人惊讶的是，并非经常出现这种情况），但最终我会得到简单，清晰，易于理解/维护的代码，运行在简单，精心设计的数据库中。

分享并享受。