什么时候应该规范化？

#1 楼

在进行OLAP操作时进行归一化，在OLTP时进行归一化（来自“归一化”部分下的链接文章）在线
分析处理（OLAP）。 OLTP应用程序的特点是大量的小额交易，例如在
超市结帐柜台更新销售记录。期望每个事务
将使数据库保持一致状态。相比之下，用于OLAP操作的数据库主要是“大部分读取”的数据库。
OLAP应用程序倾向于提取长时间积累的历史数据。对于此类数据库，冗余数据或“非规范化”数据可能会促进商业智能应用程序。
具体来说，星型架构中的维表通常包含
非规范化数据。在提取，转换，加载（ETL）处理期间，必须仔细控制非规范化或冗余数据，并且在状态保持一致之前，不允许用户查看数据。星型模式的规范化替代方案是
雪花模式。在许多情况下，随着计算机和RDBMS软件变得越来越强大，对非规范化的需求已经减弱，但是
由于数据量随着硬件和软件性能的增长而普遍增加，因此OLAP数据库通常仍然使用非规范化的
模式。

非规范化还用于提高小型
计算机（如计算机收银机和移动设备）的性能，因为
这些可能会使用数据
当平台不存在RDBMS时（例如Palm），或者不对数据进行任何更改而迅速处理时，也可以使用非规范化。
响应至关重要。

#2 楼

归一化直到感到痛苦，反归一化直到起作用（即：性能可以接受）:)

#3 楼

应用受控的非规范化的一个可能合理的原因是，它是否使您能够对数据应用某些完整性约束，而这在其他情况下是不可能的。大多数SQL DBMS对多表约束的支持非常有限。在SQL中，有时实现特定约束的唯一有效方法是确保约束所涉及的属性都存在于同一表中，即使规范化要求它们属于不同的表也是如此。

受控的非规范化意味着实现了机制，以确保不会由于冗余数据而引起不一致。在确定是否值得进行非规范化时，需要考虑这些额外控制措施的成本以及数据不一致的风险。 DBMS否则不允许的。根据物理数据独立性原则，DBMS应该具有配置内部存储结构的方法，而不必不必要地更改数据库中数据的逻辑表示。不幸的是，许多DBMS严重限制了任何给定数据库模式可用的物理实现选项。它们往往仅通过支持所需逻辑模型的次优实现而损害物理数据库的独立性。可以决定性能的物理实现功能-功能，例如内部数据结构，文件，索引，硬件等。规范化和非规范化与性能或存储优化无关。

#4 楼

如对此问题的答案所建议的，如果您经常访问计算的数据，请进行非规范化。如果负载配置文件读取繁重，则存储和维护计算数据的成本通常会比一遍又一遍地重新计算数据的成本要低。

#5 楼

我通常会进行非规范化，以便可以在有约束的情况下强制执行数据完整性。一个示例是该站点上最近出现的一个问题-我在另一张表中复制一列，以便可以使用CHECK约束将其与另一列进行比较。这种技术的另一个示例是我的博客文章。

除非将此类功能包装在从CHECK约束调用的标量UDF中，否则不能使用CHECK约束来比较不同行或不同表中的列。如果您实际上需要比较不同行或不同表中的列以实施业务规则怎么办？例如，假设您知道医生的工作时间，并且想要确保所有约会都适合工作时间？当然，您可以使用触发器或存储过程来实现此业务规则，但是无论是触发器还是存储过程都不能100％保证您的所有数据都是干净的–有人可以禁用或删除触发器，请输入一些脏数据，然后重新启用或重新创建触发器。也有人可以绕过存储过程直接修改您的表。无论哪种方式，您最终都可能在不了解业务规则的情况下得到违反数据的数据。只要遵守所有约束条件，就可以建立业务规则。

又一个示例是一种强制时间段无间隙和无重叠的方法。