面向对象编程与关系型数据库间的不一致(Object-relational impedance mismatch)

转载自：http://t.dbdao.com/archives/why-is-mongodb-wildly-popular.html

“如果你光给我看代码而不让我了解数据结构，我会很迷茫。如果让我了解数据结构，我就明显不再需要经常查看你的代码了。” – 由Eric Raymond写于《The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary》，1997年

语言创新

编程的基本任务是告诉计算机做某些事的方法。正因如此，许多在软件开发领域的创新是语言创新，这种创新在于使程序员能更简单有效地指示计算机的操作。

尽管计算机以二进制运行，然而我们并不会以这种方式与它们交流。每隔十年，更高级别编程语言不断出现，而程序员的自我表达能力也随之不断提高。这些创新中包括了对如何表达数据结构，以及如何表达算法的改进。

面向对象编程与关系型数据库间的不一致(Object-relational impedance mismatch)

几乎所有的现代编程语言支持面向对象（OO），当我们用代码建立对象模型时，我们通常使用原始类型（整数，字符串等），数组和对象的组合。

虽然每一种语言处理细节的方式不同，嵌套对象结构的想法已经成为我们用来描述“东西”的通用语言。

我们用来持久化数据的数据结构却并没有以同样的速度发展改变。在过去30年，持久性数据的主要数据结构一直是表 – 一个由包含标量值（整数，字符串等等）列组成的行集合。这是一个关系型数据库的世界，从1980年开始流行，它的事务性，快速查询，空间使用效率，比同时代的其他数据库系统更佳，另外它还有一支强大的Oracle销售团队。

这面向对象代码建模方式和持久化数据(通过表)存储方式之间的不同，一直是困扰许多程序员的源头。数千年来人们都在改变数据形态的问题上，即在物理形式和关系形式之间转换投入了大量的努力。

所谓对象 – 关系映射系统（Object-Relational Mapping systems ，ORMs）的工具，存在于每个面向对象的语言中。然而就算是有了这些工具，几乎所有的程序员会抱怨做O / R映射，不管通过何种方式，都是一件费时的苦差事。

Ted Neward的话直击其要害：“对象 – 关系映射工作是就如越南战争般困难重重。”

viet-300x230

在90年代，对象数据库有做过尝试，但没有真正替代关系型数据库的技术出现。文件型数据库，特别是MongoDB，是首个成功的Web时代对象存储。正因如此，它在很长时间将代表持久性数据结构的第一大语言创新。与平面的，二维的表相反，对应记录将以富对象，递归对象，N维对象（又名文件）集合来进行存储。

一个例子：博客

对于博客文章。在你进行代码建模博客文章时，你可能会有类/对象结构，但如果你使用关系型数据库来存储你的博客数据，每个条目会被传到几个表(dbdao.com)。

blog-relational-1024x578

作为一个开发者，你需要知道在关系模型中如何在“博文”对象和放置他们的组表之间进行转换。

一种不同的方法

使用MongoDB，博客帖子可以存储在单个集合，每个条目看起来像这样：

{
_id: 1234,
author: { name: “Bob Davis”, email : “bob@bob.com” },
post: “In these troubled times I like to …”,
date: { $date: “2010-07-12 13:23UTC” }, location: [ -121.2322, 42.1223222 ], rating: 2.2, comments: [ { user: “jgs32@hotmail.com”, upVotes: 22, downVotes: 14, text: “Great point! I agree” }, { user: “holly.davidson@gmail.com”, upVotes: 421, downVotes: 22, text: “You are a moron” } ], tags: [ “Politics”, “Virginia” ] } 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 { _id: 1234, author: { name: “Bob Davis”, email : “bob@bob.com” }, post: “In these troubled times I like to …”, date: {$date: “2010-07-12 13:23UTC” },
location: [ -121.2322, 42.1223222 ],
rating: 2.2,
comments: [
{ user: “jgs32@hotmail.com”,
upVotes: 22,
downVotes: 14,
text: “Great point! I agree” },
{ user: “holly.davidson@gmail.com”,
upVotes: 421,
downVotes: 22,
text: “You are a moron” }
],
tags: [ “Politics”, “Virginia” ]
}
通过文档数据库，你的数据存储与在程序中表现的几乎一样。没有复杂的映射工作（尽管人们往往选择把对象绑定到特定代码类的实例）。

MongoDB的优势在哪？

MongoDB在为那些最现代的网络应用程序的对象实例进行建模时（无论应用面向消费者还是企业）都表现出色：

帐户和用户配置文件：可自如地存储地址阵列

CMS：MongoDB的灵活模式在内容类型的异构集合上具有优势

表单数据：MongoDB能使表单数据结构变得更简便

博客/用户生成的内容：可使复杂关系的数据集中在一个对象上

消息：对于每个消息或消息类型，轻松改变其消息元数据，而无需要维护分散的表集合

系统配置：不错的配置值对象图，这在MongoDB中很平常

记录任何类型的数据：结构化日志数据是未来趋势

图形：对象和指针 – 一个完美的结合

基于位置的数据：MongoDB理解地理空间坐标并原生支持地理空间索引

展望：数据将成为入口 (dbdao.com)

Eric Raymond在《The Cathedral and the Bazaar》一书中的名言（改写自更早的Fred Brooks的 《The Mythical Man-Month》 ：

“如果你光给我看代码而不让我了解数据结构，我会很迷茫。如果让我了解数据结构，我就明显不再需要经常查看你的代码了。”

数据结构体现了我们的程序和理念的精髓。因此，作为程序员，我们支持不断创新，这使我们可以更简便地定义表达数据结构来进行应用领域建模。

人们经常问我为什么MongoDB如此广受欢迎。我告诉他们这是一个数据结构的问题。(dbdao.com)

虽然MongoDB可能受到其他NoSQL数据库技术在可拓展性方面的阻挠，MongoDB的快速成功很大程度上是得益于其作为一种数据结构存储的创新，简易并有表达力地对我们应用程序的核心的“东西”进行建模。出于这个原因，MongoDB，或者一些非常类似技术，将成为运营数据存储的主导数据库范式，而关系数据库作为一种专门的工具作为补充。

在代码和数据库中保持一致的基本数据模型在大多数使用情况下是一种更优越方法，因为它极大地简化了应用程序的开发任务，消除了复杂的映射关系。在基于JSON的文档数据库中看来这明显（如果还没有，将来会的）是做了正确的事，就像是10gen公司的人们已经在做的，这代表着一个重大创新。