6

当从相对未规范化的形式中获取数据库并对其进行规范化时，如果有的话，资源利用率可能会发生什么变化？

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

更多的表也意味着需要更多的连接（可能）来获取抽象出来的数据，因此人们会期望系统需要执行的连接数量更多会产生某种影响。

那么，规范化未规范化的数据库对资源使用有什么影响（即会发生什么变化）？

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

4

8 回答 8

13

这实际上无法以一般方式回答，因为影响会根据所讨论数据库的具体情况和使用它的应用程序而有很大差异。

所以你基本上陈述了对影响的一般预期：

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

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

注意：这假设我们正在谈论谨慎和有意的非规范化。如果您指的是与没有经验的开发人员共同使用的“在数据出现时将一些表放在一起”的方法，我会冒险声明规范化将减少各个级别的资源需求；）

编辑：关于 cdeszaq 添加的特定上下文，我会说'祝你好运';）

显然，有超过 300 个表并且没有限制（！），您的问题的答案肯定是“标准化将减少所有级别的资源需求”（并且可能非常显着），但是：

重构这样的烂摊子将是一项艰巨的任务。如果只有一个应用程序在使用这个数据库，那已经很可怕了——如果有很多，它可能会变成一场噩梦！

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

不要忽视它是一个正在运行的系统——即使它又丑又可怕，根据你的描述它还没有（还）坏掉;-)

于 2009-09-04T13:54:02.917 回答
6

“规范化”仅适用于并且专门用于数据库的逻辑设计。

数据库的逻辑设计和数据库的物理设计是两个完全不同的东西。数据库理论一直希望事情是这样的。忽略/忽视这种区别的开发人员（出于无知、粗心、懒惰或任何其他所谓但无效的“原因”）占绝大多数的事实并不能使他们正确。

可以说逻辑设计是否规范化，但逻辑设计本身并不带有任何“性能特征”。就像'c:=c+1;' 本质上不带有任何性能特征。

物理设计确实决定了“性能特征”，但是物理设计根本不具备“规范化与否”的质量。

这种对“规范化损害性能”的错误看法实际上只是证明了当今存在的所有 DBMS 引擎都严重缺乏物理设计选项。

于 2009-09-04T20:31:18.557 回答
3

强调之前发帖者提出的一些观点：您当前的模式真的非规范化了吗？设计数据库的正确方法（恕我直言）是：

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

（非规范化可能还有其他原因，但我能想到的唯一原因是政治原因——必须匹配现有代码，开发人员/经理不喜欢它，等等）

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

于 2009-09-04T14:19:37.410 回答
3

您的问题有一个非常简单的答案：这取决于。

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

我对非规范化的建议：只有在真的很痛苦时才这样做，并确保在任何插入、更新或删除后维护数据完整性时涵盖所有场景。

于 2009-09-04T13:51:06.743 回答
2

我发现在某些情况下，标准化会提高性能。

小桌子阅读速度更快。与规范化设计相比，严重非规范化的数据库通常具有 (a) 更长的行和 (b) 更多的行。

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

于 2009-09-04T14:05:08.737 回答
1

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

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

于 2009-09-04T16:15:08.853 回答
1

我想详细说明Henrik Opel 的 #3 要点。开发成本可能会上升，但并非必须如此。事实上，数据库的规范化应该简化或启用诸如 ORM、代码生成器、报告编写器等工具的使用。这些工具可以显着减少在应用程序的数据访问层上花费的时间，并将开发转移到添加业务价值。

你可以在这里找到关于规范化数据库开发方面的一个很好的 StackOverflow 讨论。有很多很好的答案、评论和值得思考的事情。

于 2009-09-22T14:27:45.950 回答
1

一方面，您最终将不得不进行结果集计算。例如，如果你有一个Blog, 有多个Posts，你可以这样做：

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

比哪个更贵

select PostCount from Blog where ID = @BlogID

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

当然，对于第二个选项，您必须处理保持数据完整性，但如果第一个选项足够痛苦，那么您就可以让它工作。

小心你不要犯过早优化。以规范化的方式进行，然后根据需求衡量性能，只有当它达不到要求时，你才应该考虑去规范化。

于 2009-09-04T13:47:06.717 回答