database - 过度规范化

Question

何时将数据库设计描述为过度规范化？这种特征是绝对的吗？还是取决于它在应用程序中的使用方式？谢谢。

Answer 1

在一般意义上，我认为过度规范化是指当您执行如此多的 JOIN 来检索数据时，它会导致显着的性能损失和数据库死锁，即使您已经调整了索引。显然，对于像 MySpace 或 eBay 这样的大型应用程序和网站，去规范化是一项扩展需求。

作为几家小型企业的开发人员，我告诉你，根据我的经验，从规范化 -> 非规范化总是比反过来更容易，实际上反过来（为了避免数据重复，现在业务大约一年后要求发生了变化）要困难得多。

当我读到诸如“您应该将地址放在客户表中而不是单独的地址表中以便避免加入”之类的一般性陈述时，我不寒而栗，因为您只知道一年后有人会要求您这样做带有您完全没有预见到的地址的东西，例如维护审计跟踪或为每个客户存储多个地址。如果您的数据库允许您创建索引视图，则您可以回避该问题，直到您的数据集如此之大以至于它不可能存在或由单个服务器或一组服务器提供服务 1-写，多读环境。对于我们大多数人来说，我认为这种情况不会经常发生。

当有疑问时，我的目标是第三范式，但有一些例外（例如，让一个字段包含一个分隔字符串的 CSV 列表，因为我知道我永远不会从另一个角度查看数据）。当我需要整合时，我会先查看我的视图或索引。希望这可以帮助。

Answer 2

这始终是应用程序领域的问题。这通常是一个正确性问题，但有时是一个性能问题。

在一种情况下，我可以想到一个过度规范化的初步案例：假设您有一个订单 + 订单项，订单项引用 productID，并将定价留给 product.price。由于这引入了时间耦合，因此您错误地进行了标准化，因为过度标准化会影响已发货的订单，除非价格绝对不会改变。您当然可以争辩说这只是一个建模错误（如评论中所示），但在大多数情况下，我也将归一化不足视为建模错误。

另一类与性能相关。原则上，我认为通常有比非规范化数据更好的性能解决方案，例如物化视图，但如果您的应用程序遭受许多连接的性能后果，那么评估非规范化是否可以帮助您可能是值得的。我认为这些案例经常被过分强调，因为人们有时会在正确分析他们的应用程序之前达到非规范化。

人们还经常忘记替代方案，例如保持数据库的规范形式并使用仓储或其他策略来处理经常读取但不经常更改的数据。

Answer 3

标准化是绝对的。数据库遵循范式，或者不遵循。有六种范式。大多数情况下，他们的名字从第一到第五。另外还有一个 Boyce-Codd 范式。

规范化的存在正是为了一个目的——防止“更新异常”。

标准化不是主观的。这不是判断。每个表和表之间的关系要么遵循标准形式，要么不遵循标准形式。

因此，您不能“过度规范化”或“规范化不足”。

话虽如此，归一化有性能成本。有些人选择以各种方式进行非规范化以提高性能。最常见的合理非规范化是打破 3NF 并包含派生数据。

一个常见的错误是破坏 2NF 并在键值和非键值之间存在函数依赖的重复副本。这需要额外的更新或者——更糟糕的是——触发以保持副本并行。

事务性数据库的非规范化应视具体情况而定。

数据仓库也很少遵循任何事务规范化规则，因为它（基本上）从未更新。

“过度规范化”可能意味着数据库由于大量连接而太慢。这也可能意味着数据库已经超出了硬件。或者应用程序没有被设计为可扩展的。

这里最常见的问题是人们在交易进行时尝试使用交易数据库进行报告。事务的锁定会干扰报告。

然而，“归一化不足”意味着存在 NF 违规，并且正在进行不必要的处理来处理复制数据和纠正更新异常。

Answer 4

当性能成本超过对应用程序预期目的的收益时。

Answer 5

规范化您的 OLTP 数据库，并非规范化您的 OLAP 数据库。每个人都有一个决定其架构的使命。与规范化事务数据库一样，数据仓库的存在是有原因的。一个完整的系统需要两者。

Answer 6

很多人都在谈论性能。我认为一个关键问题是灵活性。一般来说，你的数据库越规范化，它就越灵活。

我们目前使用“过度规范化”的数据库，因为在我们的操作环境中，客户需求每月都会发生变化。通过“过度规范化”，我们可以相应地采用我们的软件，而无需更改数据库结构。

Answer 7

我对此的看法：

总是尽可能地标准化。我通常对规范化很着迷，并尝试设计一些可以处理所有可以想到的未来扩展的东西。我最终得到的是一个非常灵活的数据库设计......而且不可能实现。

然后真正的工作开始了：去规范化。在这里，您解决了您所知道的实施有问题和/或由于连接过多而会减慢查询速度的问题。

这样你就知道你为了什么让设计可用。

编辑：文档！我忘了提到记录非规范化非常重要。当您接管一个项目以了解选择背后的原因时，这非常有帮助。

Answer 8

第三范式（3NF）被认为是许多合理的数据库应用程序的最佳规范化级别。在这种状态下，正如 Bill Kent 曾经总结的那样，每个“非关键字段 [在特定关系数据库管理系统或 RDBMS 中的每个表中] 都必须提供关于键、整个键的事实，而且仅钥匙。” 3NF 是由 EF Codd 引入的术语，数据库管理关系模型的发明者。通常，软件应用程序所依赖的数据，尤其是用于在线事务处理系统 (OLTP) 的应用程序，将在 3NF 中表现良好。根据定义，这种范式通过要求行/列数据的最小重复来减小数据库大小，并最大限度地提高查询效率和应用程序维护的便利性。3NF 通过要求将数据库的表（即它的模式）分解为由主键/外键关联的单独表来实现这一点——基本上直到 Kent 的规则成立（好吧，为了便于阅读，我已经这样说了，但是3NF 的实际定义比这要详细得多）。相反，过度规范化意味着增加相关表之间的查询所需的连接数。这是因为将数据库模式分解为比 3NF 更细化的级别。然而，尽管超过 3 度的归一化通常可以被认为是过度归一化，但“过度归一化”一词的负面含义有时可能是没有根据的。由于应用程序软件的复​​杂性和多功能性，在某些设计上需要 4NF（及以上）的应用程序中可能需要过度规范化。这方面的一个例子是针对某些行业的高度可定制和可扩展的商业数据库程序，在该程序中它被出售给需要开放 API 的最终用户。但是反过来也可能是可取的——即非规范化——最值得注意的是，在设计在线分析处理 (OLAP) 数据库时，该数据库严格用于汇总 OLTP 数据库中的数据，仅用于查询/报告——例如数据仓库。在这种情况下，数据必须以高度非规范化的格式（即 1NF 或 2NF）存在。通常在这些限制下——当对高效查询和报告有很高的要求时——我们发现数据库和应用程序程序员调用数据库，“过度规范化”。但是作为Redgate的 Tony Davis 曾经说过——考虑到当今更先进、更高效的数据库软件和存储系统——“查询中的多个连接对性能的影响可以忽略不计。如果你的数据库很慢，那不是因为它”过度标准化'！” 所以总而言之，这种特性——超标准化——不是绝对的，它取决于它在应用程序中的使用方式。用肯特的话来说，“规范化规则旨在防止更新异常和数据不一致。. . [但是] 在考虑到实际绩效要求时，没有义务对所有记录进行完全规范化。. . 规范化设计通过最小化冗余和不一致性来增强数据的完整性，但对于某些检索应用程序可能会带来一些性能成本。. . [因此，] 标准化的可取性必须根据其对检索应用程序的性能影响进行评估。"

Answer 9

..或达到您的 RDBMS 将执行的连接数量的限制。

Answer 10

如果连接过多会影响性能，则为报告目的创建非规范化表可以加快速度。通过将数据复制到新表中，可以运行完全没有连接的报表。

Answer 11

根据我的经验，我从未见过包含邮政地址的规范化数据库，因为将地址存储为字符串通常是可以接受的。理想情况下，会有国家、县/州、城市、地区和街道的表格。我没有遇到任何需要在街道上报告的人，所以没有必要。这些地址仅用于邮政联系，因此被视为一个实体。