SQL泛化/专门化、数据冗余

我有三张表：动作、信息、喜欢。它定义了继承，消息和类是动作的子对象（专门化）

消息等都有userId列和createdAt列。当然，这些应该被移动到parrent表操作，并从Message和Likes中删除。但只有一种情况下，我需要从数据库中同时选择消息和喜欢的内容，在其他情况下，我只选择其中一种，消息或喜欢

在child和parrent表中复制userId和createdAt可以吗？它占用了磁盘空间，但节省了一次加入—每次需要userId和createdAt时，我都必须加入消息和操作。还有，我需要更改我当前的代码

---

你有什么建议？

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

我建议您在知道存在真正的问题之前不要复制列。我在墙上贴了一些关于性能优化的观察结果，以提醒自己在类似情况下应该做什么：

直到它坏了，它才坏

你不能改进你没有测量的东西

程序在最糟糕的地方花费了惊人的时间

让它跑起来。让它正常运行。让它跑得很快。

• 优化实际上是你最不应该做的事情
• 更快地做错事情并没有多大好处

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

不能对未规范化的内容进行反规范化

如果第三范式从他们的屏幕后面跳出来，像女妖一样尖叫，并在他们头上敲打棒球棒，大多数开发者都不会知道

反规范化被认为是解决数据库性能问题的灵丹妙药。问题是，那些建议去规范化的人往往从未规范化过任何东西

“基于性能原因的非规范化”是草率“做我们一直做的事情”思维的借口，特别是当这种非规范化被纳入设计时

根据我的经验，在编写代码之前，我无法确定性能问题将发生在哪里。问题似乎总是发生在我从未想过要去看的地方。因此，我发现我的最佳选择始终是编写最简单、最清晰的代码，并尽可能简单地设计数据库，尽我所能遵循规范化规则，然后处理出现的问题。可能仍然存在需要注意的性能问题（但是，令人惊讶的是，并不是经常发生），但最终我将使用简单、清晰、易于理解/维护的代码，在一个简单、设计良好的数据库上运行

---

分享并享受。

谢谢，这篇文章很棒。基本上，我应该消除重复并重写遗留代码？：-）@彼得：谢谢。如果涉及到遗留代码，则情况显然不同，并且您可能无法（由于时间限制或组织限制）重写所有内容。我的评论是针对新的数据库和代码的。这是我个人的项目，所以时间或其他什么都不重要，相关的遗留代码也不是什么大问题。从您的帖子中可以清楚地看到，在所有情况下，最好通过连接父表来获取数据，即使我只需要一个子表。