上击发布了一篇文章来介绍演进的数据库设计（EDBD）的优点，这是一种从敏捷/极限编程世界中衍生出来的数据库设计的一种新方法。为了从另一个角度来看问题，我们请Mark WhiteHorn对这篇文章进行了评论，并给出它对演进的数据库设计（EDBD）和传统的数据库设计（TDBD）方法的看法。
什么是传统的数据库设计？
正如对于敏捷建模和极限编程没有统一的定义一样，传统数据库设计（TDBD）也是如此。如果三个传统的数据库设计者在一起，你会发现关于如何最好的设计数据库的四个看法。但是，出于讨论的目的，我们假定其为基于用户的开发，逻辑和物理建模。
首先业务分析人员与用户进行交流，因为用户心中有自己的模型；根据这些交流的结果，分析师建立一个逻辑模型。这就是典型的实体关系（Entity Relationship，ER）模型，它可以被用户否决从而重新设计。开发者然后根据这个模型增加烦琐的技术元素（诸如数据类型、索引等等），这将逻辑模型转化为一个物理模型。最后，他们在建模工具中按下一个虚拟的按钮，得到适合他们所选引擎的数据库模式。
不支持我们，就是反对我们？
这篇文章表现出来的一个方面是对传统的数据库设计者的轻视：“数据库设计人员未能充分理解它的基本原理和技术…他们有很多东西需要做。”和“还需要做更多的工作来让现有的数据库从业人士认同它，并克服长期以来一直存在的许多错误的看法。”
尽管这样说会引起演进的数据库设计（EDBD）支持者的极大的满足，它也会疏远那些这篇文章试图所说服的那些人，我认为这是一件可耻的事情。传统数据库设计这样已经确立的方法会因为受到各种挑战而获益，因为它可以被完善或被取代。
这篇文章提出这样一个前提：‘数据库设计的传统方法很明显已经不忙满足我们的需要’，那么让我们来看一下这个观点。
传统数据库设计不能满足我们的要求了吗？
让我们看一下原文中如何描述传统数据库设计已经不满足用户要求了吧，‘多长时间你就会发现数据库的表中具有不再被使用的字段？或者有些表的字段是否被用于好几种用途，因为这个表增加需要的字段已经非常困难；或者发现有存在数据质量问题的表’的确，我不能否认这些都是一些存在的问题。
但是，根据这些就能判定传统数据库设计有缺陷吗？不，演进的数据库设计（EDBD）支持者在这一点上进行争论，就如同说‘我们看到了大量的坏数据库，因此这个设计过程是有缺陷的，因此我们必须改变它。’问题就在于此，条件和结论之间不符合逻辑。
你可以这样想一下，“我们看到了大量的道路交通事故，因此交通法规就是存在缺陷的，因此我们必须修改它。”事实上，大多数交通事故的发生是因为人们没有正确的按照交通规则来驾驶。规则规定人们不能喝酒驾驶，但是人们不遵守。人们往往超速驾驶；他们还闯红灯等等。
类似的方式，我同意存在很多有缺陷的数据库，但是这并不能说明传统数据库设计存在缺陷的。
为什么会有这些设计坏的数据库？
根据我的经验，有两个主要的原因会导致数据库被设计的比较差。
1、即使在今天，大多数商业数据库通常最初是由业界专家设计的，而不是专业数据库开发者。我认为由财务人员设计的财务数据库虽然在提供的功能上可能会表现更好，但是在设计上表现一般。
2、设计商业数据库的计算机专家虽然拥有世界上最好的愿望，但是没有经过数据库开发者的培训，而且不具备对设计任务或相关任务的全面了解。设计不是根据传统模型来进行的。
在我看来，这两个原因是出现大量设计较差的数据库现象的主要问题。
因此，我们认为任何传统的数据库是设计良好的。有很多普通的例子可以证明这一点，良好的设计，良好的结构，良好的结构化，它们表现当然不会差。在完美公正的世界中，它们自然会吸引人们的注意力。但是因为很明显的原因，它们没有达到这种表现。
传统模型能够处理变化吗？
演进的数据库设计（EDBD）社区针对传统数据库设计的另一个主要的批评是，传统设计方法在处理变化上表现很差。‘不幸的是，传统数据库社区的人们认为改进数据库模型是一件非常难的事情，因此从来不去考虑如何来实现它。’
那么，传统数据库设计有机制来处理和实施改变吗？当然有。用户们提出一个修改建议后，随后进行讨论以确保对需要修改的内容有个全面的了解，然后修改被整合到逻辑模型中。然后体现着物理模型中；修改计划然后被制定、测试并最终应用到运行数据库中。这种方法有什么不好吗？在我看来，这个过程是非常完善的，是非常明智的。
当然，这种方法也不一定是总是成功的。有的传统数据库是非常难于改进的。毫无疑问，这是一个非常严重的问题，我认为查找这种现象的原因也是非常重要的。在我看来，主要有两个原因。
1、数据库最初的设计非常良好，为了保持这个优势，开发团队对修改管理控制的非常严格。修改过程被弄得非常烦琐以致于难于实行。修改过程进展的会非常缓慢，太缓慢以致于没有实际效果。
2、数据库最初设计良好，但是由于疏于对修改的管理，经常发生修改，导致其结构化降低，在以后进行修改的时候就越来越困难了。
实际上，很多数据库开发者会认识到这一点。猛然的对数据库模式的改变会给开发团队和开发资源（时间和精力）带来挑战。他们抱怨这样的改变会降低数据库的结构化和生存能力。每一次他们被告知“是的，是的；非常感谢你们为此做出的工作。我们相信你们所说的一切对企业是非常重要的，但是这是一次意外，你们要为这一次改变努力一下。我们随后将提供关于这个改变的相关文档，请不必担心。”最终的结果是，数据库的结构变得非常粗糙，以致于由此带来的问题比修补的问题还要多。
我不是在想方设法来为这些问题辩解，而只是想解释为什么现在出现这么多结构化比较差、难于维护的数据库。很显然，很多演进的数据库设计（EDBD）的支持者来自于应用程序开发世界，出现在传统数据库世界中的问题曾经让他们备受折磨。说实话，这种问题也曾经让我发狂，这就是为什么我如此同情他们的原因；我相信他们是为了解决了一个真正的问题。
传统数据库设计需要被替换吗？
不，我不认为这些设计或维护的比较差的数据库的存在能证明当前的设计方法存在缺陷。通过存在的非常成功的传统数据库设计项目，我们可以说，不是设计方法有缺陷，而是方法的实施存在缺陷。
但是，这当然不是说我们已经证明传统数据库设计比演进的数据库设计更高级。那么需要解决的下一个问题是：
如果所有因素相等，谁更有可能成功，传统数据库设计（EDBD）？还是演进的数据库设计（TDBD）？
这是个非常重要的问题，正确的答案是“我不知道”。没有人知道。许多人有自己的观点，但是没有人真正知道答案。问题在于两种数据库设计的样本大小不一样。传统数据库设计（TDBD）的应用非常多，而演进的数据库设计（EDBD）则非常少。
但是我们可以肯定的事情是，许多因素可以导致一个数据库设计项目成功或失败。常见的因素有以下集中，不过不仅限于它们。
1、设计者和开发团队的智慧
2、他们的动机
3、他们被给予的资源
4、他们所采用的方法
5、他们如何紧密的遵守这些方法
我们真正争论的地方在于第四点与其他四点相比的重要性。我个人的看法是，上面所列出的其余四点是一个数据库设计项目成功的重要因素，相比之下第四点就显得无关紧要了。你的看法可能不同，不过如果我的看法是正确的，那么修改所采用的方法就是修正问题的最没有效果的方法了。
为了从另一个方式来看待这个问题，有人想使用缺乏热情、未经训练和资源不足的人，来尝试一个演进的数据库设计（EDBD）项目吗？
我们应该做什么来解决比较差的数据库设计问题？
我认为通常可以从以下5个方面入手：
•雇用更有能力的人来进行设计和维护
•努力培训和激励他们
•给他们合适的资源以实现所选择的方法
•不要不经过合适的考虑就强迫他们实施改变
•确保他们不会陷入太多的麻烦的修改管理
我认为这些解决方案听起来容易，那么为什么它们很少在实践中实施呢？因为实际上做起来很难。高能力的人非常难于招聘，能善于激励项目组成员的管理者也非常少，而项目资源的提供则设计到投入资金。这些非常现实的问题导致了能做到以上几点并非易事。而这些实际的问题即使我们转向演进的数据库设计也不会有多大改观。
如何看待演进的数据库设计？
我尽力不想把这篇文章写成一篇对演进的数据库设计（EDBD）的攻击文章，因为我这样做只会降低工作效率。但是，我还是认为有一个让我担心问题值得一提-传统的数据库设计（TDBD）以ER建模为中心，而演进的数据库设计（EDBD）则反其道而行之。
为什么我认为这是一个问题？在企业的要求之间总是存在一些压力；它同事需要我们做到以下两点：
1、对昨天的数据库进行修改，以适应正在改变的业务过程。
2、提供清晰、一致、可以经得住时间跨度考验的分析信息
为了确保第二点，我们需要对数据结构和数据要表达的“意思”有一个清晰的总体认识。这就是为什么传统数据库设计（TDBD）不仅仅以ER建模为中心，而且在用户、逻辑和物理模型方面进行设计考虑的众多原因之一。这绝不是“瞎忙”；对于让我们能跟踪数据和同等重要的数据意义，它是非常重要的。
我的感觉是，演进的数据库设计的出发点来自于应用程序开发社区。从坏处想，应用程序开发者倾向于将应用程序看作国王，而将数据库作为不方便的复杂的充满障碍的仓库，他们偶尔才会被迫来存放数据。他们倾向于选择支持第一点的过程。
传统的数据库设计（TDBD）的出发点则在数据库开发者社区。从坏处想，数据库开发者将数据库看作神殿，而将应用程序看作一个令人讨厌的过程。他们则倾向于选择第二点。
无论我们的背景如何，我们的工作是运用我们的共同的见解，来提供这两种选择之间的最好的平衡。
阅读(282) | 评论(0) | 转发(0) |
