【51CTO精选译文】我对关系数据库呈现爆炸式增长一直感到很惊讶，至少在过去10年，应用程序都是直接与数据库对话的，大部分都是通过参数来访问数据库的。高级开发人员可能会将应用程序的SQL语句放在源代码之外，可能是一个文本文件，也可能是数据库中的一个配置表。后来我们看到了数据层的崛起，再往后发展就变成了使用Web Service对应用进行松耦合。现在许多开发人员添加了一个对象——角色建模（ORM）系统或在数据库上进行抽象设计，只是为了产生一个数据层。
过去20年，开发人员一直在尝试找出关系数据库要如何改变才能更好地满足人们的需要。我对关系数据库管理系统（RDBMS）相关的历史有一点了解，一般来说，关系数据库的速度快，兼容ACID，标准化（大部分是）以及易于理解。开发人员可以在一个厂商的关系数据库基础上开发应用程序，然后不用费太多精力就可以转移到了一个厂商的关系数据库上。实际上，许多系统要受不同数据库厂商的制约，只不过大部分开发人员自己还不知道罢了。
另一个需要考虑的事情是关系数据库的替代品（如面向对象的数据库管理系统，OODBMS）在过去已经有很多讨论了，但这个替代品速度缓慢，完全专有化，厂商不多，缺乏ACID兼容，对于大多数开发人员而言都还很神秘。这算不上是一个成功的替代方案，尝试OODBMS的人都是引火烧身，最近主流的OODBMS是Smalltalk。51CTO之前也报导过其他的关系数据库替代品，如NoSQL，Oracle Coherence和Terracotta等等。
令人沮丧的是关系数据库却一直在稳步增长，关系数据库根本不能满足大多数应用程序中包含的业务模型，业界喜欢称之为“阻抗不匹配”。
为什么我对关系数据库没有好感？
我负责的应用程序有数据存储需求（我负责编程和支持这些企业应用套件），但最近出现了极不正常的数据需求。这里有一个很好的例子：对于那些允许用户创建他们自己的内容类型的应用程序（不只是他们自己的内容），Sharepoint和Team Foundation Server就是这样的实例，在数据库级架构方面已经做得很好了，可以满足它们的需求，但尽管如此，你看到的存储系统仍然很混乱，这里有成堆的列，但它们的目的不是由数据库结构自身决定的，而是由每一列的内容类型决定的，这意味着开发人员必须寻求其它方式，被迫重建大量的逻辑。
过去几年开发工具厂商开始注意到这个问题，它们发布了一些列的产品和组件提供了一些帮助，但大多数仍然是在现有关系数据库基础架构上进行构建的，这样做也是为了保护客户已有的投资。
此外，出现了一种不合乎逻辑的现象，人们开始追捧“沉没成本”（也叫做“赔了夫人又折兵”或“把钱扔到水里了”），在这种情况下，开发人员宁愿向应用程序中增加复杂的层，这样肯定会显著增加时间成本，同时也使应用程序维护和调试变得更加困难了，但这样可以弥补应用程序和数据库之间的“阻抗不匹配”。ADO.NET实体框架Hibernate下的系统都是很好的例子。我曾经研究过ADO.NET实体框架，但我决定不去碰它，它太过于复杂和庞大了，虽然我也看到过有些做得好的系统隐藏了复杂性，如OutSystem的敏捷平台。
同时，面向对象数据库管理系统已经取得了很大的进步，在我朋友的建议下，我下载了db4O，虽然我还没有使用它，但我的朋友说它确实不错，我还是很相信我这位朋友的话的，我打算最近对db4O做一番研究。许多面向对象的数据库目前仍然兼容ACID。通过文档和一些例子可以看出，它们比关系数据库的工作界面要少得多，也没有在ORM根据和类似的系统上花太多的精力。虽然原始数据访问速度比关系数据库要慢，特别是读的速度，但当你说明了应用程序中不同的数据访问层，加上转换数据库数据到本地语言对象的成本，面向对象的数据库速度会更快。
我认识的大部分开发人员在这个问题上困扰了很久，但他们没有意识到还有另外的选择，我认为现在是时候尝试新事物了，再也不能让应用程序因受关系数据库的限制变得复杂难懂了。（51CTO编辑注：事实上，关系数据库的终结随着云计算的稳步到来而越来越近，已成为业界中所公认的一个趋势。）
原文：It's time to consider alternatives to RDBMS
作者：Justin James
【编辑推荐】
