database-design - 什么时候是打破规范化规则的好时机？

Question

请给出您对不规范化是个好主意的情况的意见。我刚刚目睹了一位架构师和 DBA 之间的激烈讨论，他们坚持认为数据库过于规范化。

Answer 1

规则是规范化直到它受到伤害，然后非规范化直到它起作用。 (谁说的？)

一般来说，当我有很多父子关系时，我经常进行非规范化，我知道我经常需要加入五六个大表来获取一条数据(例如客户端 ID)并且不需要任何大部分时间来自中间表的信息。如果可能的话，我会尝试对不会频繁更改的内容(例如 id 字段)进行非规范化。但是，无论何时您进行非规范化，您都必须编写触发器或其他一些过程(但通常会在无法通过 PK/FK 关系和级联更新处理的情况下触发)以确保数据保持同步。如果您未能在数据库级别执行此操作，那么您将遇到数据完整性问题，并且您的数据将变得无用。不要认为您可以通过应用程序代码维护非规范化。这是灾难的秘诀，因为数据库经常从应用程序以外的地方更新。

正确地反规范化会减慢插入、更新和删除的速度，尤其是当您需要处理大量数据时。它可能会也可能不会提高选择查询速度，具体取决于您需要如何查询数据。如果您最终需要执行大量自联接来获取数据，那么您最好不要进行非规范化。永远不要在没有测试的情况下进行非规范化，看看您是否提高了性能。请记住，当许多用户使用它时，减慢插入/更新/删除将对系统产生整体影响。通过非规范化来解决一个问题，你可能会在整个系统中引入一个更糟糕的问题。不要只测试您想要加速的一个查询，而是测试整个系统的性能。您可能会加快每月运行一次的查询速度，并减慢每天运行数千次的其他查询速度。

非规范化通常用于数据仓库，这是一种特殊情况，因为它们通常按计划自动更新，而不是由用户一次更新一条记录。专门从事数据仓库的 DBA 也倾向于构建它们，他们知道如何避免数据完整性问题。

另一种常见的非规范化技术是为与不需要使用实时数据运行的复杂报告相关的数据创建临时表。这是一种穷人的数据仓库，不应该在没有按计划更新临时表的方法的情况下完成(尽管您可以侥幸逃脱，但它使用的服务器资源在大多数情况下可以更好地用于其他地方。 ) 通常，当系统上的用户很少并且比实时数据滞后一整天时，会更新这些类型的表。不要考虑这样做，除非您为其暂存数据的查询确实很慢并且无法进行优化。许多慢查询可以在不进行非标准化的情况下进行优化，因为开发人员通常使用最容易理解的方式而不是最高效的方式来选择数据。