在大规模系统中最好的范式是什么？

Question

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

Answer 1

那得看情况。您将如何处理这些数据？

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

在OLAP的情况下，您可能想要考虑设计一个星形或雪花模式，而不用担心范式。在OLTP的情况下，规范化的数据库可能比非规范化的数据库提供更好的结果。

正确的数据有多重要？一个自相矛盾的数据库可能会变得一团糟。两个被认为是等价的输出却是相互矛盾的？这怎么会发生呢？

好吧，如果数据库在数据库中的多个位置存储相同的事实，那么它可能会设法将该事实的不同且相互矛盾的版本存储在不同的位置。数据库如何在多个位置存储一个事实的多个副本？如果它不是完全规范化的。

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

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

有些人建议您进行规范化，以节省数据库空间。磁盘空间很便宜。有些人担心处理时间。这通常是微不足道的。由于额外的磁盘访问造成的延迟是显而易见的，但通常是可以管理的。

然而，在某些情况下，未能标准化可能会导致性能灾难。这是与繁重的负载和保守的并发控制相关的瓶颈。大多数DBMS服务器采用保守的并发控制策略，以保护数据不受神秘的时间依赖错误的影响，如幻影更新。即使您可以放松并发控制策略，这样做也要自担风险。

标准化较差的数据库通常存在这些瓶颈或“热点”。当系统负载较轻时，它们不会浮出水面。该系统可能会通过beta测试，但在实际生产中只会变得缓慢。备份网站的数据库因存在此缺陷而臭名昭著。规范化可以通过保持更新事务的简单性来帮助您避免这种情况。

那么你的目标应该是什么呢？当我在构建数据库时，我通常以3NF或BCNF为目标。3NF非常简单。您只需确保非key数据依赖于key，整个key，除了key之外别无他物(所以帮助我Codd)。我通常不必担心4NF或5NF，但同样，这取决于您的情况。

Answer 2

那得看情况。

我建议尽可能地规范化-例如: 5NF -然后为了性能或报告的目的在必要的地方添加非规范化字段(向现有的规范化数据库添加非规范化元素要比标准化已经在使用的非规范化结构容易得多)