为什么许多设计忽略了RDBMS中的规范化？

Question

我看到了很多设计，在决策阶段，规范化不是第一个考虑的问题。

在许多情况下，这些设计包括30多个列，主要的方法是“把所有的东西放在同一个地方”。

根据我的记忆，规范化是第一件，最重要的事情之一，那么为什么有时它会如此轻易地掉下来呢？

编辑：

好的架构师和专家选择非规范化的设计，而没有经验的开发人员选择相反的设计，这是真的吗？有什么理由反对在你的设计开始时考虑到标准化？

Answer 1

在问题和一些答案中内置的假设是，规范化是良好的数据库设计的同义词。事实上，情况往往并非如此。规范化是实现特定设计目标的一种方法，如果您严重依赖数据库来强制执行有关数据元素之间关系的“业务规则”，则是一种需求。

规范化给您带来了一些关键的好处：

1. 最大限度地减少冗余数据量。
2. 最大限度地利用数据库内置的完整性机制(外键约束、唯一性约束)来确保数据的完整性。
3. 减少每一行的列数，在某些情况下提高IO的效率。大行要花更长的时间才能检索到。

尽管如此，有许多正当的理由使之去奥马尔化：

1. 性能，特别是在分析方面，可能会因标准化而受损。对于针对关系数据库的分析，非规范化维数模型是标准方法。
2. 在数据库内部执行数据完整性的好处开始下降。随着越来越多的开发集中于面向对象的中间层(通常是执行业务规则)，依赖数据库中的关系约束就不那么重要了。
3. 正如其他人所提到的，正常化将使检索相关数据所需的查询复杂化。

目前还不清楚标准化是否是良好设计的标志。在某些情况下，规范化是存储空间占优势的时期，而且编码业务规则的大部分责任都在数据库中(考虑一下2层客户机服务器应用程序，存储过程中的大部分业务逻辑，如果不是全部的话)。很可能是许多项目偏离了基于良好架构决策的规范化，而不是对数据库设计原则的不太了解。

上述评论中引用的Jeff的文章提供了一些很好的详细讨论-- “也许正常化是不正常的”。

Answer 2

1. 许多开发人员不知道或不关心规范化，也不关心数据建模或数据库。
2. 对于一些工作来说，这并不重要。
3. 有时候，确实有一个很好的理由去使正常，例如，使一个特别困难的工作量表现良好。
4. 与1990年代和2000年代相比，关系数据库概念最近不那么流行了。开发人员往往会受到时尚的影响，即使他们声称自己非常理性。争论味觉是没有意义的。

在历史上，正常化也是一个近乎宗教争论的领域，所以我不愿多说。

Answer 3

在大型项目中，特别是大型机项目中，情况并非如此。事实上，如果您搜索职务站点，您将看到数据建模师的几个职位。而且，在一个表上有许多列并不违反规范化。尽管如此，你的观察对于某些项目是有效的。

数据库设计是构建质量系统所需的技能之一。尽管如此，一些开发人员对数据库设计还不太了解，仍然被分配到数据建模和数据库设计的任务中。有些项目甚至跳过数据建模。许多项目的重点主要是编码和前端设计。

数据库设计不佳的另一个因素是，规范化不是一个琐碎的话题，特别是对于第四个NF、第五个NF等等。我看过的大多数书都不能很好地解释这些形式。通常有坏的例子和太多的理论。这使得这个话题不那么受欢迎。

数据库设计中的错误很难产生，除非您在测试期间查找它们或遇到它们。没有数据库设计质量的标准让错误发生的可能性更大。

此外，一些项目没有遵循严格的开发方法(促进数据库设计的方法)，因此，业务分析师、开发人员和DBA之间的职责会混合在一起，任务也会丢失。开发人员用OO和UML交谈，其中DBA使用DD，有些用ERD，可能很多人没有UML或OO。总之，缺乏知识、缺乏清晰的资源、缺乏统一的语言来描述数据和缺乏方法都是罪魁祸首。