规范化数据库对资源的影响是什么？

Question

从相对未规范化的表单中获取数据库并对其进行规范化时，资源利用率中的更改可能会有什么期望？

例如，规范化通常意味着从更少的表创建更多的表，这意味着数据库现在具有更多的表，但是其中许多表非常小，允许常用的表更好地适应内存。

表的数量越多，也意味着需要更多的连接（可能）来获取抽象出来的数据，因此系统需要从更多的连接数中获得某种影响。

那么，规范化非规范化数据库会对资源使用产生什么影响（即什么会改变）？

---

编辑： 为了添加一些上下文，我有一个包含300多个可怕表的现有（即遗留）数据库。大约1/2的数据是TEXT，另一半是char字段或整数。没有任何限制。我问的原因主要是获取更多信息，以说服其他人事情需要改变，并且不会降低性能或可维护性。不幸的是，我必须说服那些非规范化数据库的性能优势，以尽可能避免规范化。

Answer 1

这无法以一般方式得到解答，因为影响会因严重而异，具体取决于相关数据库的具体情况以及使用它的应用程序。

所以你基本上表达了对影响的一般期望：

1. 随着冗余数据被删除，存储的整体内存需求将下降
2. CPU需求可能上升，因为查询可能变得更加昂贵（请注意，在许多情况下，对规范化数据库的查询实际上会更快，即使它们更多复杂，因为查询引擎有更多优化选项）
3. 开发资源需求可能上升，因为开发人员可能需要构建更复杂的查询（但另一方面，您需要更少的开发工作来维护数据完整性）

所以唯一真正的答案是通常的：它取决于;）

注意：这假设我们正在讨论谨慎和有意的非规范化。如果你指的是'只是把一些表放在一起，因为数据出现'的方法与没有经验的开发人员共同使用，我会冒这样的说法：规范化将减少所有级别的资源需求;）< / p>

---

编辑：关于cdeszaq添加的具体情况，我会说'祝你好运，'）

显然，有超过300个表和没有约束（！），你的问题的答案肯定是'正常化将减少所有级别的资源需求'（并且可能非常重要），但

重构如此混乱将是一项重大任务。如果只有一个应用程序使用这个数据库，它已经是可怕的 - 如果有很多，它可能会成为一场噩梦！

因此，即使从长远来看规范化会大幅减少资源需求，但根据具体情况，可能不值得。这里的主要问题是关于长期范围 - 这个数据库有多重要，它将被使用多长时间，将来会有更多的应用程序使用它，当前的维护工作是否持续增加等等......

不要忽视它是正在运行的系统 - 即使它是丑陋可怕的，根据你的描述它还没有被打破; - ）< / p>

Answer 2

“规范化”仅将仅 应用于数据库的逻辑设计。

数据库的逻辑设计和数据库的物理设计是两个完全不同的事物。数据库理论一直都是为了这样做。忽视/忽视这种区别的开发人员（出于无知或出于疏忽，或出于懒惰或出于任何其他所谓但无效的“理由”）的绝大多数，都不能使他们做对。

逻辑设计可以说是规范化的，但逻辑设计并不固有地带有任何“性能特征”。就像'c：= c + 1;'并不具有任何性能特征。

物理设计确实确定了“性能特征”，但物理设计再次没有“标准化与否”的质量。

这种对“正常化损害性能”的错误认识实际上就是具体的证据，即当今存在的所有DBMS引擎都严重缺乏物理设计选项。

Answer 3

对你的问题有一个非常简单的答案：它取决于。

首先，我将你的问题重新定义为“非规范化的好处是什么”，因为规范化应该作为默认值（作为纯逻辑模型的结果）完成，然后非规范化可以是适用于性能至关重要的非常具体的表格。非规范化的主要问题是它可能使数据完整性管理复杂化，但在某些情况下的好处大于风险。

我对非规范化的建议：只有当它真正受到伤害时才会这样做，并确保在任何插入，更新或删除后保持数据完整性时都能涵盖所有方案。

Answer 4

我发现在某些情况下，规范化会提高效果。

小表阅读速度更快。严重非规范化的数据库通常具有（a）更长的行和（b）比标准化设计更多的行。

读取更少的短行意味着更少的物理I / O.

Answer 5

要强调先前海报所提出的一些观点：你当前的架构是否真的是非规范化的？设计数据库的正确方法（imho）是：

• 尽可能了解要建模的系统/信息
• 构建完全规范化模型
• 然后，如果您认为有必要，以受控方式进行非规范化以提高性能

（可能有其他理由进行非规范化，但我能想到的唯一理由是政治性的 - 必须与现有代码相匹配，开发人员/经理不喜欢它等等。）

我的观点是，如果你从未完全规范化，你没有非规范化数据库，你就有一个非标准化。而且我认为如果这些数据库的礼貌用语较少，你可以考虑更具描述性。

Answer 6

首先，您最终必须进行结果集计算。例如，如果您有Blog个Post，则可以执行以下操作：

select count(*) from Post where BlogID = @BlogID

比

贵

select PostCount from Blog where ID = @BlogID

如果你不小心，可能导致SELECT N+1问题。

当然，对于第二个选项，您必须处理保持数据完整性的问题，但如果第一个选项足够痛苦，那么您可以使其正常工作。

小心你不要对premature optimisation犯规。以规范化的方式进行，然后根据需求来衡量性能，并且只有当它看起来不正常时才会出现。

Answer 7

规范化模式往往对INSERT / UPDATE / DELETE执行得更好，因为没有“更新异常”，需要进行的实际更改更加本地化。

SELECT混合在一起。非规范化实际上是一种连接的实现。毫无疑问，实现连接有时会有所帮助，但是，实现通常非常悲观（可能更常见），所以不要假设非规范化会对你有所帮助。此外，规范化模式通常较小，因此可能需要较少的I / O.连接不一定是昂贵的，所以不要自动假设它会。

Answer 8

我想详细说明Henrik Opel's #3 bullet point。开发成本可能上升，但他们没有必要。实际上，数据库的规范化应该简化或启用ORM，代码生成器，报表编写器等工具的使用。这些工具可以显着减少在应用程序的数据访问层上花费的时间，并将开发工作移至添加业务值。

您可以找到关于规范化数据库的开发方面的好的StackOverflow讨论here。有很多好的答案，评论和要考虑的事情。