为什么会有这些设计坏的数据库？

   根据我的经验，有两个主要的原因会导致数据库被设计的比较差。

   1、即使在今天，大多数商业数据库通常最初是由业界专家设计的，而不是专业数据库开发者。我认为由财务人员设计的财务数据库虽然在提供的功能上可能会表现更好，但是在设计上表现一般。

   2、设计商业数据库的计算机专家虽然拥有世界上最好的愿望，但是没有经过数据库开发者的培训，而且不具备对设计任务或相关任务的全面了解。设计不是根据传统模型来进行的。

   在我看来，这两个原因是出现大量设计较差的数据库现象的主要问题。

   因此，我们认为任何传统的数据库是设计良好的。有很多普通的例子可以证明这一点，良好的设计，良好的结构，良好的结构化，它们表现当然不会差。在完美公正的世界中，它们自然会吸引人们的注意力。但是因为很明显的原因，它们没有达到这种表现。

传统模型能够处理变化吗？

   演进的数据库设计（EDBD）社区针对传统数据库设计的另一个主要的批评是，传统设计方法在处理变化上表现很差。‘不幸的是，传统数据库社区的人们认为改进数据库模型是一件非常难的事情，因此从来不去考虑如何来实现它。’

   那么，传统数据库设计有机制来处理和实施改变吗？当然有。用户们提出一个修改建议后，随后进行讨论以确保对需要修改的内容有个全面的了解，然后修改被整合到逻辑模型中。然后体现着物理模型中；修改计划然后被制定、测试并最终应用到运行数据库中。这种方法有什么不好吗？在我看来，这个过程是非常完善的，是非常明智的。

   当然，这种方法也不一定是总是成功的。有的传统数据库是非常难于改进的。毫无疑问，这是一个非常严重的问题，我认为查找这种现象的原因也是非常重要的。在我看来，主要有两个原因。

   1、数据库最初的设计非常良好，为了保持这个优势，开发团队对修改管理控制的非常严格。修改过程被弄得非常烦琐以致于难于实行。修改过程进展的会非常缓慢，太缓慢以致于没有实际效果。

   2、数据库最初设计良好，但是由于疏于对修改的管理，经常发生修改，导致其结构化降低，在以后进行修改的时候就越来越困难了。

   实际上，很多数据库开发者会认识到这一点。猛然的对数据库模式的改变会给开发团队和开发资源（时间和精力）带来挑战。他们抱怨这样的改变会降低数据库的结构化和生存能力。每一次他们被告知“是的，是的；非常感谢你们为此做出的工作。我们相信你们所说的一切对企业是非常重要的，但是这是一次意外，你们要为这一次改变努力一下。我们随后将提供关于这个改变的相关文档，请不必担心。”最终的结果是，数据库的结构变得非常粗糙，以致于由此带来的问题比修补的问题还要多。

   我不是在想方设法来为这些问题辩解，而只是想解释为什么现在出现这么多结构化比较差、难于维护的数据库。很显然，很多演进的数据库设计（EDBD）的支持者来自于应用程序开发世界，出现在传统数据库世界中的问题曾经让他们备受折磨。说实话，这种问题也曾经让我发狂，这就是为什么我如此同情他们的原因；我相信他们是为了解决了一个真正的问题。