我认为目前，NoSQL 数据存储的整个想法和文档数据库的概念是如此新颖，与驱动关系存储的既定想法不同，因此目前很少（如果有的话）最佳实践。
在这一点上，我们知道在 CouchDB（或任何其他文档数据库）中存储数据的规则与关系数据库的规则大不相同。例如，规范化和针对 3NF 的目标几乎是一个事实，而不是人们应该努力争取的事情。一个常见的例子是一个简单的博客。
在关系存储中，您将有一个表格，分别用于“帖子”、“评论”和“作者”。每个作者会有很多帖子，每个帖子会有很多评论。这是一个运行良好的模型，并且可以很好地映射到任何关系数据库。但是，在 docDB 中存储相同的数据很可能会大不相同。您可能会拥有类似 Post 文档的集合，每个文档都将嵌入自己的 Author 和 Comments 集合。当然，这可能不是您可以做到的唯一方法，这在某种程度上是一种妥协（现在查询单个帖子很快——您只需执行一个操作并取回所有内容），但您无法维护作者和帖子之间的关系（因为它都成为帖子文档的一部分）。
我也见过使用“类型”属性的示例（在 CouchDB 示例中）。当然，这听起来是一种可行的方法。它是最好的吗？我没有头绪。当然，在 MongoDB 中，您会在数据库中使用单独的集合，这使得 type 属性完全是无稽之谈。不过在 CouchDB 中……也许这是最好的。其他选择？每种类型的文档都有单独的数据库？这似乎有点循环，所以我自己倾向于“类型”解决方案。但这只是我。也许有更好的东西。
我意识到我在这里闲聊了很多，说的很少，很可能是你不知道的。不过我的观点是——我认为这取决于我们对我们拥有的工具和我们正在使用的数据进行试验，随着时间的推移，好的想法将被传播并成为最佳实践。我只是觉得你在游戏中问得太早了。
“NoSQL”应该更多地是关于构建数据存储以遵循您的应用程序需求，而不是关于构建应用程序以遵循某种结构——这更像是传统的SQL 方法。
不要“仅仅因为”就放弃关系数据库；仅当您的应用确实需要时才这样做。