我才刚刚开始使用非关系数据库，而且我仍在努力思考它并找出最好的模型是什么。我只能代表 CouchDB。
不过，我有一些初步结论：
您是否提出了在非关系世界中效果更好的替代设计？
设计重点转移：文档模型（对应于数据库表）的设计变得几乎无关紧要，而一切都取决于设计视图（对应于查询）。
文档数据库交换了复杂性：SQL 具有不灵活的数据和灵活的查询，文档数据库则相反。
CouchDB 模型是“JSON 文档”（基本上是嵌套的哈希表）的集合。每个文档都有一个唯一的 ID，并且可以通过 ID 轻松检索。对于任何其他查询，您编写“视图”，它们被命名为 map/reduce 函数集。视图将结果集作为键/值对列表返回。
诀窍是您不会像查询 SQL 数据库那样查询数据库：运行视图函数的结果存储在索引中，并且只能查询索引。（如“获取所有内容”、“获取密钥”或“获取密钥范围”。）
SQL 世界中最接近的类比是，如果您只能使用存储过程查询数据库 - 您想要支持的每个查询都必须预先定义。
文件的设计非常灵活。我发现只有两个约束：
- 将相关数据一起保存在同一个文档中，因为没有任何内容对应于连接。
- 不要使文档太大以至于更新太频繁（例如将当年的所有公司销售额放在同一个文档中），因为每个文档更新都会触发重新索引。
但一切都取决于设计视图。
我发现使用 CouchDB 比任何 SQL 数据库更好的工作数量级的替代设计是在系统级别而不是存储级别。如果你有一些数据并且想要将它们提供给一个网页，那么整个系统的复杂度至少会降低 50%：
- 没有设计数据库表（小问题）
- 没有 ODBC/JDBC 中间层，所有查询和事务都通过 http （中等问题）
- 来自 JSON 的简单 DB 到对象映射，与 SQL 中的映射相比，这几乎是微不足道的（重要！）
- 您可以跳过整个应用程序服务器，因为您可以将文档设计为使用 AJAX 直接由浏览器检索，并在它们显示为 HTML 之前添加一点 JavaScript 修饰。（巨大的！！）
对于普通的 web 应用程序，基于文档/JSON 的数据库是一个巨大的胜利，而不太灵活的查询和一些额外的数据验证代码的缺点似乎是一个很小的代价。
你有没有碰到任何看似不可能的事情？
还没有。Map/reduce 作为一种查询数据库的方法是陌生的，并且比编写 SQL 需要更多的思考。原语数量相当少，因此获得所需的结果主要是如何指定键的创造性问题。
查询不能同时查看两个或多个文档是有限制的——没有连接或其他类型的多文档关系，但到目前为止没有什么是不可克服的。
作为一个示例限制，计数和总和很容易，但不能通过 CouchDB 视图/查询计算平均值。修复：分别返回 sum 和 count 并在客户端计算平均值。
您是否使用任何设计模式弥合了差距，例如从一种模式转换到另一种模式？
我不确定这是否可行。它更像是一种完全的重新设计，例如将功能风格的程序转换为面向对象的风格。一般来说，文档类型比 SQL 表少得多，每个文档中的数据多。
一种思考方式是查看插入和常见查询的 SQL：例如，当客户下订单时会更新哪些表和列？哪些是月度销售报告？该信息可能应该放在同一个文档中。
即： 一份订单文档，包含客户 ID 和产品 ID，并根据需要复制字段以简化查询。文档中的任何内容都可以轻松查询，任何需要在 Order 和 Customer 之间进行交叉引用的内容都必须由客户完成。因此，如果您想要一份按地区划分的销售报告，您可能应该在订单中输入地区代码。
你现在甚至做显式数据模型（例如在 UML 中）吗？
抱歉，在文档数据库之前也从未做过太多 UML :)
但是您需要某种模型来说明哪些字段属于哪些文档以及它们包含哪些类型的值。供您以后参考，并确保每个使用数据库的人都知道约定。例如，如果您在文本字段中存储日期不会再出现错误，并且任何人都可以添加或删除他们喜欢的任何字段，因此您需要验证代码和约定来弥补不足。特别是如果您使用外部资源。
您是否错过了 RDBMS 提供的任何主要的额外服务？
没有。但我的背景是 Web 应用程序开发人员，我们只在必须的范围内处理数据库 :)
我曾经工作的一家公司制造了一个产品（一个 web 应用程序），该产品旨在跨多个供应商的 SQL 数据库运行，并且“额外服务”因数据库而异，以至于必须为每个数据库单独实现。因此，将功能移出 RDBMS 对我们来说工作量更少。这甚至扩展到全文搜索。
因此，无论我放弃什么，都是我一开始从未真正拥有过的东西。显然，您的体验可能会有所不同。
一个警告：我现在正在做的是一个用于财务数据、股票报价等的网络应用程序。这非常适合文档数据库，从我的角度来看，我可以轻松获得数据库的所有好处（持久性和查询）。
但是这些数据彼此相当独立，没有复杂的关系查询。按股票代码获取最新报价，按股票代码和日期范围获取报价，获取公司元信息，这几乎就是全部。我看到的另一个例子是博客应用程序，博客也没有大量复杂的数据库模式。
我想说的是，我所知道的所有文档数据库的成功应用首先是与没有太多相互关系的数据：文档（如在谷歌搜索中）、博客文章、新闻文章、财务数据.
我希望有些数据集映射到 SQL 比映射到文档模型更好，所以我想 SQL 会继续存在。
但是对于我们这些只想要一种简单的方法来存储和检索数据的人——我怀疑我们当中有很多人——文档数据库（如在 CouchDB 中）是天赐之物。