标准化应该走多远？

我的数据库中有大量数据。我的表格式良好，并且它们之间的关系良好，并且数据有些冗余。但是，归一化应该走多远？过多的标准化是否存在性能缺陷？

您应该走的越远越好。当然。〜问题可能是这有点艺术，这就是为什么这不是一门纯科学。

我们的主要产品是分析和报告系统，因此在这方面，我们有很多详细的记录。最初，我们为它设计了一些子记录，并在一个通用ID上包含大量联接，但是我们发现，如果我们对几个字段进行非规范化处理，就可以减少很多联接，并且可以避免很多性能问题。

但是我们只知道，因为我们1）创建了“规范化”设计，2）开始使用它，3）在数十个表中进行了数亿行的数据分析之后，描述了实际性能。

最后的故事是，直到我们进行概要介绍，我们才能确定到底什么对我们有用。我们喜欢规范化的想法，因此我们可以更轻松地进行更新，但是最终，实际性能是决定性因素。这是我对您的建议：个人资料，个人资料，个人资料。

仅当标准化足够好地支持您的数据模型以保证它时，它才是目标。它旨在成为允许增长，管理和可维护性的指南。请记住，有关规范化的书或其作者都不会构建或维护您的数据库或其应用程序。

这里有关于“太多标准化”的很好的阅读。

而且，是的，过多的规范化可能会对性能产生影响。这将是在表的更深遍历中，以在将状态指示符表拉到单独的表中时进行选择。有人会说，这通常在更新速度（将状态文本从“良好”更改为“良好”等）或维护性方面被否定了。

我建议您阅读Chris Date近期著作中的以下附录：

标准化的两个欢呼

通过考虑目标是什么以及与目标的对立程度，我们可以很容易地看到标准化不是万能药。

我必须明确指出，我不希望将本节中的评论视为任何攻击。我坚信，除了完全归一化的设计外，任何其他事物都应严格禁止使用。

我认为查看显式添加的非规范化（添加聚合值或将主表中的某些字段复制到详细副本）也同样重要。

争论主要是一些性能争论。

如果执行此操作，则触发器将更新这些字段，并由数据库决定是否保持一致。

我完全同意@jcolebrand。在为应用程序设计模型时，应规范化所有可能的方法。但是随后您应该分析在模型上建立的查询，尤其是那些经常执行的查询。

我自己的经验：需要两次连接才能到达的属性（这意味着要联接三个表）将主要是性能消耗。更糟糕的是，它用于在线交易。我对属性进行非规范化，因此只需要一个联接，并要求程序员调整其应用程序以进行查询并更新属性。现在效果更好了...

换句话说，您应该在标准化与性能之间取得平衡。