Java 开发 2.0: 通过 CouchDB 和 Groovy 的 RESTClient 实现 REST

核心提示： 面对文档的数据库关系数据库基本上主导了数据库市场，但其他类似的数据库 — 包括 面向对象 和 面向文档 数据库，Java 开发 2.0: 通过 CouchDB 和 Groovy 的 RESTClient 实现 REST(2)，两者在面向关系的世界中极为不同 — 也不时发挥

面对文档的数据库

关系数据库基本上主导了数据库市场。但其他类似的数据库 — 包括 面向对象 和 面向文档 数据库，两者在面向关系的世界中极为不同 — 也不时发挥着举足轻重的作用。CouchDB 是一种面向文档的数据库。它是无模式的，并且允许您以 JavaScript Object Notation (JSON) 字符串的形式来存储文档。

JSON

JSON 是一种轻量级的数据交换格式，同时也是 Web 应用程序的替代格式。它类似于 XML，但远没有它那么详细。得益于其轻量级特性，它正成为 Web 的 通用语。

试想一个违规停车罚单。该罚单将涵盖以下项目：

违规的日期

时间

位置

车辆的描述

牌照信息

违规情况

罚单上收集的格式和数据因管辖权而异。即使对于单一管辖权限内的标准停车罚单来说，它们的内容也很有可能存在不同。举例来说，警官在开罚单时可以不填写时间，或者可以省略车型，而只填写牌照的详细信息。地点可以是两条街道的组合（比如 Fourth 和 Lexington 的交汇处），或者是某个固定地址（比如说 19993 Main Street）。但所采集信息的语义大抵相似。

罚单的数据点可以在关系数据库中建模，但详细信息却有点麻烦。举例来说，如何有效在关系数据库中捕获某个交汇点呢？并且在没有街道交汇的情况下，数据库是否会使用空字段来表示第二个地址呢（假定建模方式为在各列中捕获不同的街道名）？

在这些情况下，关系数据库的抽象化程度可能 会稍高一些。所需的信息已经采用了文档（罚单）的形式。为什么不将数据建模为文档呢？这样可以不用死守严格的关系模式，而只需要大致遵循高级模式的语义。这正是 CouchDB 的用武之地。它允许您以灵活的方式来对这些域类型进行建模 — 成果是一个完备的文档，它没有模式，而是使用与其他文档大致相似的蓝图。