数据库解冻

几年前，我听到编程语言界的人谈论由 Java 引起的语言“核冬天”。当时的感觉是，每个人都如此趋同于 Java 的计算模型（C# 在那时被认为只是 Java 的翻版），以至于编程语言的创造力消失了。这种感觉现在正在消退，但也许更重要的是，一种更长更深的冻结正在开始解冻——关于数据库的思考。

当我开始从事软件开发职业时，我与一些宣扬关系型数据库的人一起工作。我在面向对象的世界里遇到了他们。当时，许多人预计 OO 数据库将成为数据库的下一个进化步骤。正如我们现在所知，这种情况并没有发生。如今，关系型数据库已经深深地嵌入其中，以至于大多数项目一开始就假设使用 RDBMS。

在上周的 QCon 上，有一系列强烈的演讲质疑了这种假设。当然，其中一个让我印象深刻的是 Tim Bray 的主题演讲，他进行了 旅程，涵盖了数据管理的几个方面。在此过程中，他强调了一些有趣的项目。

• Drizzle 是一种关系型数据库，但它摒弃了现代关系型产品的许多机制。我认为它是一种 RISC RDBMS——只支持关系型功能集的基本要素。
• Couch DB 是许多尝试进入分布式键值对模型的尝试之一。虽然数据模型非常简单（实际上只是一个哈希表），但这种方法在高流量网站中变得非常流行。
• Gemstone 是面向对象数据库群体中的一员，我发现 Gemstone-Smalltalk 组合是一个非常强大的开发环境（优于其大多数后继者）。Gemstone 仍然是一个利基玩家，但可能会通过 Maglev 获得更多关注——这是一个将 Gemstone 的方法（本质上是数据库和虚拟机的融合）引入 Ruby 世界的项目。

除了这个演讲之外，还有由 Kresten Krab Thorup 主持的关于替代数据库的完整 轨道。在那里提到的其他工具之一是 Neo4J——一种图（网络）数据库工具，获得了 Jim Webber 的一些罕见的赞誉。

关于这些产品，自然而然地要问的问题是，为什么它们应该在 ODBMS 失败时胜出？是什么改变了环境，可以解冻关系型数据库的控制？关于为什么关系型数据库如此占主导地位有很多假设——我认为，它们的统治地位与其在数据管理中的作用关系不大，而与其在集成中的作用关系更大。

对于当今许多组织来说，主要的集成模式是 共享数据库集成——多个应用程序通过使用一个公共数据库来集成。当您拥有这些 集成数据库 时，重要的是所有这些应用程序都能轻松访问此共享数据——因此 SQL 的重要作用。SQL 作为一种几乎标准的查询语言的作用，一直是关系型数据库占主导地位的核心。

数据库领域的升温源于集成替代方案的存在——特别是 Web 服务的兴起。在各种旗帜下，应用程序通过 HTTP 传递文本（主要是 XML）文档来相互通信的运动正在蓬勃发展。互联网和内联网形式的网络使这种集成模式比 SQL 更加普遍。这是一件好事，我一直不喜欢通过公共数据库紧密耦合多个应用程序的方法——你无法获得比这更严重的封装违规。

如果您将集成协议从 SQL 切换到 HTTP，那么现在意味着您可以将数据库从 集成数据库 更改为 应用程序数据库。这种变化意义重大。第一步是支持一种更简单的方法来进行对象关系映射——例如 Ruby on Rails 所采用的方法。但更重要的是，它打破了关系数据模型的束缚。如果您通过 HTTP 集成，那么应用程序如何存储自己的数据就不再重要了，这反过来意味着应用程序可以选择适合自身需求的数据模型。

我认为这并不意味着关系型数据库会消失——毕竟，它们在许多情况下是正确的选择。但这确实意味着，现在应用程序开发人员应该考虑什么才是适合他们需求的正确选择。随着非关系型项目的普及和成熟，越来越多的项目将选择其他选项。