#1 楼
您应该走的越远越好。当然。 〜问题可能是，这有点艺术，这就是为什么这不是一门纯科学。
我们的主要产品是分析和报告系统，因此在这方面，我们有很多详细的记录。最初，我们为它设计了一些子记录，并在一个公共ID上包含大量联接，但是我们发现，如果我们对几个字段进行非规范化处理，则可以消除很多联接，并且可以避免很多性能问题。
但是我们只知道，因为我们1）创建了一个“规范化”设计，2）开始使用它，3）在数十个表中进行了数亿行的数据分析之后，描述了实际性能。 >
最后的故事是，在我们进行概要介绍之前，我们不确定是否会为我们工作。我们喜欢规范化的想法，因此我们可以更轻松地进行更新，但是最终，实际性能是决定性因素。这就是我对您的建议：个人资料，个人资料，个人资料。
#2 楼
只有当标准化足以支持数据模型时，标准化才是目标。它旨在成为允许增长，管理和可维护性的指南。请记住，关于规范化的书及其作者都不会构建或维护您的数据库或其应用程序。这里有关于“标准化过多”的文章。
是的，标准化过多会对性能产生影响。当将状态指示符表拉到单独的表中时，这将是在表的更深遍历中进行。有人会说这通常在更新速度（将状态文本从“良好”更改为“良好”之类的东西）或可维护性方面被否定。
评论
这是该主题的又一佳读本，而且有趣的是qntm.org/gay
–jcolebrand♦
2011年1月11日下午5:15
#3 楼
我建议阅读Chris Date最近几本书中的以下附录：标准化的两大欢呼
标准化远非万能药，因为我们可以很容易地通过
来考虑其目标是什么，以及它如何与目标相抗衡...
我必须明确表示我不想发表评论在本节中，
被视为任何形式的攻击。我坚信，除了完全归一化的设计之外，
绝对是禁忌...
#4 楼
我认为查看显式添加的非规范化（添加聚合值或将主表中的某些字段复制到详细信息副本中）同样重要。该参数主要是一些性能参数。
如果强制执行，则这些字段将由触发器更新，并由数据库决定是否保持一致。
#5 楼
我完全同意@jcolebrand。在为应用程序设计模型时，应规范化所有可能的方法。但是随后您应该分析在模型上建立的查询，尤其是那些经常执行的查询。我自己的经验：需要两次连接才能到达的属性（即三个表已联接）将主要是性能消耗。更糟糕的是，它用于在线交易。我对属性进行非规范化，因此只需要一个联接，并要求程序员调整其应用程序以查询和更新属性。现在它的效果更好...
换句话说，您应该在规范化与性能之间取得平衡。
评论
艺术而不是科学使我相信这是伏都教。有参考吗？
– abel
2011年1月11日，9：21
@Abel一般我的轶事如何？探查器可能能够建议非规范化规则，但是这些规则来自经验丰富的程序员。所有编程都是一门艺术。稍后我会使用完整的键盘时，会发现一个更出名的人说同样的话。
–jcolebrand♦
2011年1月11日下午13:19
@Abel哦，那么一切都在（'forgiven'，'赦免'）;）：p
–jcolebrand♦
2011年1月11日14:08
@Fergus很高兴您喜欢它。我一直发现轶事效果最好。
–jcolebrand♦
2011年4月4日在6:59
@abel-“艺术是具有超过7个自由度的科学”。除了一定程度的复杂性之外，穷举解决问题的方法变得不可行。那时，基于经验的启发式方法是最有效的。令人遗憾的是，在计算领域中，除了琐碎的软件系统之外，在任何其他情况下都很难达到这种复杂性水平。
– ConcernedOfTunbridgeWells
2012年4月11日上午10:37