【发布时间】：2012-09-01 21:54:49
【问题描述】：
如果我有一个大型系统，我应该使用哪种范式：3NF、BCNF、4NF、5NF 或更高？
【问题讨论】：
标签： database-design normalization database-normalization
【发布时间】：2012-09-01 21:54:49
【问题描述】：
这取决于。您将如何处理这些数据？
您的数据库是否旨在支持在线事务处理 (OLTP)？或者它是否旨在支持在线分析处理 (OLAP) 或报告、数据集市或数据仓库活动？
在 OLAP 案例中，您可能需要考虑设计星形或雪花模式，而不必担心正常形式。在 OLTP 情况下，规范化的数据库可能比规范化程度较低的数据库提供更好的结果。
正确的数据有多重要？自相矛盾的数据库可能是一团糟。两个应该相等的输出反而相互矛盾？怎么会这样？
好吧，如果数据库在数据库的多个位置存储相同的事实，它可能会设法在不同的位置存储该事实的不同且相互矛盾的版本。数据库如何将一个事实的多个副本存储在多个地方？如果它没有完全标准化。
与每个正常形式相关联的是一个或多个更新异常，这些异常在插入、更新或删除行时可能发生。这些异常被相应的正常形式所消除。您可以通过在更新中仔细编程来避免这个问题，但避免比避免更简单。如有必要，请查看正常形式以熟悉异常情况，并确定它们对您的情况有多大的问题。
更新时的性能有多重要？在查询时？
有些人敦促您进行规范化以节省数据库中的空间。磁盘空间很便宜。有些人担心处理时间。这通常是微不足道的。额外磁盘访问导致的延迟很明显，但通常是可控的。
但是，在某些情况下，无法正常化可能会导致性能灾难。这是与重负载和保守的并发控制相关的瓶颈。大多数 DBMS 服务器采用保守的并发控制策略，以保护数据免受神秘的时间相关错误（如幻像更新）的影响。即使您可以放松并发控制策略，也有风险。
规范化不佳的数据库通常存在这些瓶颈或“热点”。当系统处于轻负载状态时，它们不会浮出水面。该系统可能会通过出色的 Beta 测试，只是为了在实际生产中慢下来。备份网站的数据库因存在此缺陷而臭名昭著。规范化可以通过保持更新事务简单来帮助您避免这种情况。
那么你的目标是什么？当我构建数据库时，我通常以 3NF 或 BCNF 为目标。 3NF真的很简单。您只需确保非关键数据依赖于密钥、整个密钥，并且只依赖于密钥（所以请帮帮我 Codd）。我通常不必担心 4NF 或 5NF，但同样，这取决于您的情况。
【讨论】：
这取决于。
我建议尽可能规范化 - 即：5NF，然后在必要时添加非规范化字段以用于性能或报告目的（将非规范化元素添加到现有规范化数据库比规范化非规范化结构要容易得多已经在使用中）
【讨论】：