database-design - 大规模系统中的最佳范式是什么？

Question

如果我有一个大型系统，我应该使用哪种范式：3NF、BCNF、4NF、5NF 或更高？

Answer 1

这取决于。

我建议尽可能规范化 - 即：5NF， - 然后在必要时添加非规范化字段以实现性能或报告目的（将非规范化元素添加到现有规范化数据库比规范化已经存在的非规范化结构要容易得多采用）

Answer 2

这取决于。你打算用这些数据做什么？

您的数据库是否旨在支持在线事务处理 (OLTP)？或者它是否旨在支持在线分析处理 (OLAP)、报告、数据集市或数据仓库活动？

在 OLAP 案例中，您可能需要考虑设计星型或雪花模式，而不必担心范式。在 OLTP 情况下，规范化的数据库可能比规范化程度较低的数据库提供更好的结果。

正确的数据有多重要？自相矛盾的数据库可能是一团糟。两个应该相等的输出反而相互矛盾？这怎么可能发生？

好吧，如果数据库在数据库的多个位置存储相同的事实，它可能会设法在不同的位置存储该事实的不同且相互矛盾的版本。数据库如何将一个事实的多个副本存储在多个地方？如果它没有完全标准化。

与每个正常形式相关联的是一个或多个更新异常，这些异常在插入、更新或删除行时可能发生。这些异常被相应的正常形式所消除。您可以通过在更新中仔细编程来避免这个问题，但避免比避免更万无一失。如有必要，请查看正常形式以熟悉异常情况，并确定它们对您的情况有多大的问题。

更新时的性能有多重要？在查询时？

有些人敦促您进行规范化以节省数据库中的空间。磁盘空间很便宜。有些人担心处理时间。这通常是微不足道的。由于额外的磁盘访问导致的延迟很明显，但通常是可以管理的。

然而，在某些地方，未能规范化可能会导致性能灾难。这是与重负载和保守的并发控制相关的瓶颈。大多数 DBMS 服务器采用保守的并发控制策略，以保护数据免受神秘的时间相关错误（如幻像更新）的影响。即使您可以放松并发控制策略，这样做也是有风险的。

规范化不佳的数据库通常具有这些瓶颈或“热点”。当系统处于轻负载状态时，它们不会浮出水面。该系统可能会通过出色的 Beta 测试，只是为了在实际生产中慢下来。备份网站的数据库因存在此缺陷而臭名昭著。规范化可以通过保持更新事务简单来帮助您避免这种情况。

So what should you aim for? When I was building databases, I generally aimed for 3NF or BCNF. 3NF is really easy. You just make sure that non key data depends on the key, the whole key, and nothing but the key (so help me Codd). I generally never had to worry about 4NF or 5NF, but again, it depends on your case.