我只是刚刚开始使用非关系型 DB，我仍然试图把我的头围绕它，并找出最好的模型是什么。

不过，我有一些初步的结论：

你想出了在非关系世界中工作得更好的替代设计吗？

设计重点转移：文档模型（对应于 DB 表）的设计变得几乎无关紧要，而一切都取决于设计视图（对应于查询）。

文档 DB 交换了复杂性：SQL 具有不灵活的数据和灵活的查询，文档 DB 则相反。

CouchDB 模型是“JSON 文档”（基本上是嵌套的哈希表）的集合。每个文档都有一个唯一的 ID，并且可以按 ID 进行简单检索。对于任何其他查询，您都可以编写“视图”，这些视图被命名为 map / reduce 函数集。这些视图以键 / 值对列表的形式返回结果集。

诀窍是，你不在你查询 SQL 数据库的意义上查询数据库：运行视图函数的结果存储在索引中，并且只有索引可以被查询。

SQL 世界中最接近的类比是，如果您只能使用存储过程查询数据库-您要支持的每个查询都必须预定义。

文档的设计非常灵活。我发现只有两个约束：

将相关数据一起保存在同一文档中，因为没有与连接相对应的内容。

不要让文档太大，以至于它们更新得太频繁（比如将公司当年的所有销售额都放在同一个文档中），因为每次文档更新都会触发重新索引。

但是一切都取决于视图的设计。

我发现 CouchDB 比任何 SQL 数据库在系统级别而不是存储级别更好的工作顺序。如果您有一些数据并希望将它们提供给网页，则整个系统的复杂性至少降低了 50 ％：

没有设计 DB 表（小问题）

没有 ODBC / JDBC 中间层，所有查询和事务都通过 http（中度问题）

从 JSON 进行简单的 DB 到对象映射，与 SQL 中的映射相比，这几乎是微不足道的（重要！）

您可以跳过整个应用程序服务器，因为您可以使用 AJAX 设计要由浏览器直接检索的文档，并在将其显示为 HTML 之前添加一点 JavaScript 抛光。（巨大！！）

对于普通的 Web 应用程序，基于文档 / JSON 的 DB 是一个巨大的胜利，不太灵活的查询和一些额外的数据验证代码的缺点似乎是一个很小的代价。

你有没有碰到任何看似不可能的事情？

还没有。Map / reduce 作为查询数据库的一种方法是不熟悉的，并且比编写 SQL 需要更多的思考。原语的数量相当少，因此获得所需的结果主要是如何指定键的创造性问题。

有一个限制，即查询不能同时查看两个或多个文档-没有连接或其他类型的多文档关系，但到目前为止没有什么是不可克服的。

作为示例限制，计数和求和很容易，但 CouchDB 视图 / 查询无法计算平均值。修复：分别返回总和和计数，并在客户端上计算平均值。

你有没有用任何设计模式来弥合差距，例如从一个到另一个的翻译？

我不确定这是可行的。它更像是一个完整的重新设计,就像将一个函数式风格的程序翻译成面向对象的风格。一般来说,文档类型远远少于 SQL 表,每个文档中的数据更多。

一种方法是查看 SQL 中的插入和常见查询：例如，当客户下订单时会更新哪些表和列？哪些用于月度销售报告？这些信息可能应该放在同一个文档中。

即：一个订单文档，包含客户 ID 和产品 ID，并根据需要使用复制字段以简化查询。文档中的任何内容都可以轻松查询，任何需要在订单和客户之间进行交叉引用的内容都必须由客户完成。因此，如果您想要按地区划分的销售报告，则应该在订单中添加地区代码。

你现在甚至做明确的数据模型（例如在 UML 中）？

对不起，在文档 DB 之前从来没有做过很多 UML:)

但是您需要某种模型来说明哪些字段属于哪些文档以及它们包含哪些类型的值。供您以后参考，并确保使用 DB 的每个人都知道约定。例如，如果您将日期存储在文本字段中，并且任何人都可以添加或删除他们喜欢的任何字段，则不再会出现错误，因此您需要验证代码和约定来弥补松弛。特别是如果您使用外部资源。

您是否错过了 RDBMS 提供的任何主要额外服务？

不。但我的背景是 Web 应用程序开发人员,我们只在一定程度上处理数据库:)

我曾经工作过的一家公司制作了一个产品（一个 webapp），该产品旨在跨多个供应商的 SQL 数据库运行，并且“额外服务”在 DB 和 DB 之间是如此不同，以至于它们必须为每个 DB 单独实现。因此，我们将功能从 RDBMS 中移出的工作较少。这甚至扩展到全文搜索。

所以无论我放弃什么，我一开始都没有真正拥有过。显然，你的经历可能会有所不同。

警告：我现在正在做的是一个用于财务数据，股票报价等的 webapp。这是一个非常好的匹配文档 DB，从我的角度来看，我得到了 DB（持久性和查询）的所有好处，没有任何麻烦。

但是这些数据彼此相当独立，没有复杂的关系查询。通过股票代码获取最新报价，通过股票代码和日期范围获取报价，获取公司元信息，这几乎就是全部。我看到的另一个例子是博客应用程序，博客的特点也不是非常复杂的数据库模式。

我想说的是，我所知道的文档 DB 的所有成功应用都是与最初没有太多相互关系的数据：文档（如 Google 搜索），博客文章，新闻文章，财务数据。

我希望有映射到 SQL 比文档模型更好的数据集，所以我想 SQL 将生存。

但是对于我们这些只想要一个简单的方法来存储和检索数据的人-我怀疑我们中有很多人-文档数据库（如 CouchDB）是天赐之物。

我认为你必须考虑到非关系型 DBMS 在数据模型上有很大的不同，因此概念数据设计也会有很大的不同。在NOSQL Google group的线程Data Design in Non-Relational Databases中，不同的范例是这样分类的：

类似 Bigtable 的系统（HBase 、 Hypertable 等）

键值商店（东京、伏地魔等）

文档数据库（CouchDB 、 MongoDB 等）

图形数据库（AllegroGraph 、 Neo4j 、芝麻等）

我主要是graph databases，使用这种范例的数据设计的优雅使我厌倦了RDBMS的缺点。我在此wiki page上放了一些使用图形数据库进行数据设计的示例，并且还有一个example of how to model基本IMDB电影 / 演员 / 角色数据。

Marko Rodriguez的演示幻灯片（slideshare）Graph Databases and the Future of Large-Scale Knowledge Management也很好地介绍了使用图形数据库的数据设计。

从 graphdb 的角度回答具体问题：

替代设计：在许多不同类型的实体之间添加关系，而无需担心或需要预定义哪些实体可以连接。

弥合差距：我倾向于根据域本身对每种情况进行不同的操作，因为我不想要“面向表的图”等。但是，here's一些有关从 RDBMS 到 graphdb 的自动转换的信息。

明确的数据模型：我做这些所有的时间（白板风格），然后使用模型，因为它是在 DB 以及。

RDBMS 世界的：创建报告的简单方法。更新：也许不是很难从图形数据库创建报告，请参阅Creating a Report for a Neo4J Sample Database。

我在我的脑海里用 CouchDB 回答这个问题，但我认为大多数其他 DB 也是如此。我们看着使用 CouchDB，但最终决定反对它，因为我们的数据访问事先不知道，可扩展性不是问题。

较硬:

在概念层面上进行重新思考，所以它“更难”，因为它只是不同。因为你必须事先知道你的数据访问模式，所以不能应用自动翻译。你至少需要添加访问模式。

一致性不是由数据库处理的，而是必须在应用程序中处理的。更少的保证意味着更容易的迁移、故障转移和更好的可扩展性，代价是更复杂的应用程序。应用程序必须处理冲突和不一致。

跨文档（或键 / 值）的链接也必须在应用程序级别上处理。

SQL 类型的数据库有更成熟的 IDE。你得到了很多支持库（尽管这些库的分层使事情比 SQL 所需的要复杂得多）。

更容易:

更快，如果你知道你的数据访问模式。

迁移 / 故障转移对于数据库来说更容易,因为作为应用程序程序员,没有向您做出任何承诺。尽管您最终获得了一致性。可能。最后。一些时间

一个键 / 值比表中的一行更容易理解。所有（树）关系都已经在中，并且可以识别完整的对象。

建模应该是相同的，但你必须小心你放在一个文档中的东西：UML 也可以用于 OO 建模和 DB 建模，这是两种不同的野兽。

我希望看到一个很好的开放式 OO 数据库与 C ＃ / Silverlight 很好地集成。只是为了使选择更加困难。:)

长期以来，对于任何大小的数据集，平面文件都被认为是晦涩难懂且不切实际的。但是，具有更多内存的更快计算机可以将文件加载到内存中并实时对其进行排序，至少对于相当小的 n 和本地单用户应用程序而言。

例如，您通常可以读取 10,000 条记录的文件，并在不到半秒的时间内对其进行排序，这是可以接受的响应时间。

当然，使用数据库而不是平面文件是有原因的-关系操作，数据完整性，多用户功能，远程访问，更大的容量，标准化等，但是计算机速度和内存容量的提高使得内存中操作数据在某些情况下更加实用。