NoSQL 的利弊
当然，无模式数据建模也有利有弊。回顾上面的比赛应用程序，它的一个优势是非常灵活。如果我决定将一个新属性(比如 SSN)添加到一个 Runner，我不必进行大幅更改 —事实上，如果我将该属性包含在构造函数的参数中，那么它就会自动添加。对那些没有使用一个 SSN 创建的旧实例而言，发生了什么事情?什么也没发生!它们拥有一个值为 null的字段。
另一方面，我已经明确表明要牺牲一致性和完整性来换取效率。这个应用程序的当前数据架构没有向我施加任何限制 —理论上我可以为同一个对象创建无限个实例。在 Google App Engine 引擎的键处理机制下，它们都有惟一的键，但其他属性都是一致的。更糟糕的是，级联删除不存在，因此如果我使用相同的技术来建模一个 “一对多” 关系并删除父节点，那么我得到一些无效的子节点。当然，我可以实现自己的完整性检查 —但关键是，我必须亲自动手(就像完成其他任务一样)。
使用无模式数据存储需要严明的纪律。如果我创建各种类型的 Races —有些有名称，有些没有，有些有 date属性，而另一些有 race_date属性 —那么我只是在搬起石头砸自己(或使用我的代码的人)的脚。
当然，也有可能联合使用 JDO、JPA 和 Google App Engine。在多个项目上使用过关系模型和无模式模型后，我可以说 Gaelyk 的低级 API 最灵活，使用最方便。使用 Gaelyk 的另一个好处是能够深入了解 Bigtable 和一般的无模式数据存储。
结束语
流行时尚来了又去，有时无需理会它们(明智的建议来自一个衣橱里满是休闲服的家伙)。但 NoSQL 看起来不太像一种时尚，更像是高度可伸缩的 Web 应用程序开发的一个新兴基础。NoSQL 数据库不会替代 RDBMS，但是，它们将补充它。无数成功的工具和框架基于关系数据库，RDBMSs 本身似乎没有面临过时的危险。
总之，NoSQL 数据库的作用是向对象 - 关系数据模型提供一个及时的替代方案。它们向我们展示，有些事情是可行的，并且 —对于一些特定的、高度强制的用例 —甚至更好。无模式数据库最适用于需要高速数据检索和可伸缩性的多节点 Web 应用程序。它们还有一个极好的副作用，即允许开发人员从一个面向域的视角、而不是关系视角进行数据建模。
