数据库去正规化的预测优势

Question

我一直被教导要努力达到数据库规范化的最高标准形式，而我们被教导伯恩斯坦综合算法如何实现3NF。这一切都很好，使数据库正常化感觉很好，因为它知道可以在保持一致性的同时修改字段。

然而，性能可能会受到影响。这就是为什么我想知道是否有任何方法来预测脱硝时的加速/减速。这样，你可以建立你的FD以3NF为特征的列表，然后尽可能少的去denormalize。我认为去角色化过多会浪费空间和时间，因为例如，巨大的blobs会被复制，或者因为您必须使用一个事务更新多个字段而更难保持一致性。

摘要:给定一个3 3NF集和一组查询，我如何预测去正规化的加速/减速？链接到报纸也很受欢迎。

Answer 1

您必须知道两个表之间的数据流，才能查看DB模型的性能。一旦有了，就可以计算给定的非正态化(例如，如果您决定复制数据)的性能变化。

一些粗略的估计可以通过你在去正规化之后需要多少新的索引来推断。每个新索引必须被单独更新和查询，这将导致性能与新索引的数量成正比。

在任何情况下，二进制数据的大块都应该存储在一个单独的表中，而不是复制。它们(通常)不被查询，而是在对其他表集进行查询之后作为最终结果集的一部分返回。

Answer 2

我不确定是否有任何学术研究，什么时候去反错可以帮助(IMHO之间有相当大的差别，是关于DB规范化和它如何在实践中工作)。

然而，有一些有趣的文章和博客关于这个_ Jeff谈到了在他的博客中的规范化，并且有一个高度可伸缩性的“答复”给他。

当去甲基化时，我建议你注意

• 每个时间单位的查询数量和类型；如果您使用insert和/或更新多于读取，去角色化将不会有多大帮助。
• 重复的信息将多久更新一次？
• 您将使用的DBMS的特性
• 信息被复制了多少次；如果您在4-5表中有相同的信息，那么将其保存在单独的表中可能会比多次复制它更快。
• 存储在DB中的预期数据量；如果记录数量增加，那么可能对少量数据起作用的数据会导致灾难。反过来说(我指的是接吻原则，而不是修复没有被破坏的东西)。

Answer 3

我认为过多的去正常化会浪费空间和时间。

在大多数中等规模的业务OLTP应用程序中，空间是不用担心的。所以留点地方吧。时间，我假设您指的是查询的性能，这通常是可以增强的，并且不会造成真正的问题，除非您有一个糟糕的设计、不足的资源、非常大的数据库、非常多的事务或以上所有内容。大多数使用当今数据库的应用程序很少会出现性能问题，这仅仅是因为数据库已经规范化了。

巨大的blobs是重复的，或者是因为很难保持一致性，因为您必须使用一个事务更新多个字段。

使数据库正常化可以确保您的设计将：

1. 没有多余的数据。
2. 不会造成大量的日志肠炎(例如有200万客户的表:更新客户集Country="USA“，其中Country="US")
3. 完全支持SQL查询。这一点是非常重要的。
4. 将驱动干净的应用程序代码。
5. 在不增加应用程序负担的情况下，通过数据库强制实现高度的数据一致性。
6. 通过不同的应用程序共享数据库中定义的业务规则，而无需在不同的应用程序中编码相同的代码。

话虽如此，规范化为所有列和表产生了最佳结构。在您的特定应用程序中，您可能并不总是需要这一点，然后考虑到您对域和应用程序的理解，您可以决定将一些表/列去规范化，作为速度的权衡。然而，这将是一个有意识的决定，而不是一个疏忽。

给定一个3 3NF集和一组查询，我如何预测去正常化的加速/减速？

如果不进行测试，就无法准确地预测性能(在编写应用程序代码之前就可以这样做)。但是，您可以通过设计消除和检测导致性能较差的因素。例如，您可以按照以下方式确定要使用的索引策略(可能存在其他技术)：

1. 生成受这些查询影响的查询和列的矩阵。
2. 查找使用最多的列。
3. 考虑在这些列上构建索引。

这主要是一个工作，你的DBA可以帮助你。性能不仅仅是正常化。磁盘卷上的数据分布、垂直表拆分、分区、索引类型和索引缓冲等方面都有。所有这些技术都应在“数据库设计”和“数据库性能调优”主题下的书籍和供应商文档中加以讨论。以上所有讨论都假设您的应用程序是OLTP应用程序。