关系数据库定义的结构非常严格，并且也通过严格的方式维护软件应用程序的数据。Apache 的开源 CouchDB 为储存数据提供一种新方法，即使用不需要模式的面向文档的数据库模型。与关系模型高度结构化的数据储存不同，CouchDB 使用基于 JavaScript 的视图模型生成结构化聚合，以半结构化的方式储存数据，并从这些半结构化文档报告结果。CouchDB 一开始是以 Web 应用程序为主要目标而开发的，并且希望发展成为用于开发 Web 应用程序的标准数据库。
什么是 CouchDB？
CouchDB 是一个开源的面向文档的数据库管理系统，可以通过 RESTful JavaScript Object Notation (JSON) API 访问。术语 “Couch” 是 “Cluster Of Unreliable Commodity Hardware” 的首字母缩写，它反映了 CouchDB 的目标具有高度可伸缩性，提供了高可用性和高可靠性，即使运行在容易出现故障的硬件上也是如此。CouchDB 初是用 C++ 编写的，但在 2008 年 4 月，这个项目转移到 Erlang OTP 平台进行容错测试。
CouchDB 可以安装在大部分 POSIX 系统上，包括 Linux® 和 Mac OS X。尽管目前还不正式支持 Windows®，但现在已经着手编写 Windows 平台的非官方二进制安装程序。CouchDB 可以从源文件安装，也可以使用包管理器安装（比如在 Mac OS X 上使用 MacPorts）。
CouchDB 是一个 Apache Software Foundation 开源项目，根据 Apache 许可 V2.0 发布。这个开源许可允许在其他软件中使用这些源代码，并根据需要进行修改，但前提是遵从版权需知和免责声明。与许多其他开源许可一样，这个许可允许用户根据需求使用、修改和分发该软件。不一定由同一个许可包含所有修改，因为我们仅维护一个 Apache 代码使用许可需知。
面向文档的数据库和关系数据库之间的区别
对很多人而言，刚接触面向文档数据库管理系统这个概念时很难理解它，尤其是长期与关系数据库打交道的人员。这是因为这两个模型相似的地方很少。
顾名思义，面向文档数据库是由一系列自包含的文档组成的。这意味着相关文档的所有数据都储存在该文档中 — 而不是关系数据库的关系表中。事实上，面向文档的数据库中根本不存在表、行、列或关系。这意味着它们是与模式无关的；不需要在实际使用数据库之前定义严格的模式。如果某个文档需要添加一个新字段，它仅需包含该字段，从而不影响到数据库中的其他文档。因此，文档不必为没有值的字段储存空数据值。
即将推出的书 CouchDB: The Definitive Guide（见 参考资料）使用名片作为 “现实的文档”，并介绍了与关系数据库相比，如何在面向文档的数据库中描述它。在关系数据库中，您需要使用 4 个以上的表来储存这些数据：一个 “Person” 表、一个 “Company” 表、一个 “Contact Details” 表和一个用于储存名片本身的表。这些表都有严格定义的列和键，并且使用一系列的连接（join）组装数据。
虽然这样做的优势是每段数据都有一个惟一真实的版本，但这为以后的修改带来不便。此外，也不能修改其中的记录以用于不同的环境。例如，一个人可能有传真号码，而另一个人没有。在名片上不应该显示 “传真：没有”，而是忽略任何关于传真的细节。
在面向文档的数据库中，每个名片都储存在各自的文档中，并且每个文档都可以定义它需要使用的字段。因此，对于没有传真号码的人而言，不需要定义传真的值，而对于有传真号码的人，则根据他们的意愿定义该值。
这两种数据库的另一个不同点是惟一标识符的储存。在关系数据库中通常可以使用主键，它由一个自动递增特性或序列生成器生成。当然，这些标识符仅相对于所使用的表或数据库是惟一的 — 其他表或数据库还可以使用它们。如果同时对不同网络上的两个数据库执行更新操作，这两个数据库不会同时准确地获取下一个惟一标识符。CouchDB 没有自动递增或序列特性。相反，它为每个文档分配一个通用惟一标识符（Universally Unique Identifier，UUID），这杜绝了其他数据库意外地选择相同的惟一标识符的情况。
面向文档数据库和关系数据库的另一个重要区别是面向文档数据库不支持连接。因此 CouchDB 中没有主键和外键，没有基于连接的键。这并不意味着不能从 CouchDB 数据库获取一组关系数据。一个称为视图的特性允许您为没有在数据库中定义的文档创建一种任意关系。这意味着您能够获得典型的 SQL 联合查询的所有好处，但又不需要在数据库层预定义它们的关系。
一定要注意，虽然面向文档数据库的操作方式不同于关系数据库，但这并不意味着它们是可以替换的。CouchDB 的目的并不是替换关系数据库，而是为那些更适合使用面向文档模型（而不是传统的关系数据模型）的项目提供一种选择，比如 wikis、博客和文档管理系统。
