假设您正在实施商店应用程序，并且要存储在数据库产品中，所有这些产品都有一个唯一的类别。在关系数据库中，这将通过具有两个表(产品和类别表)来实现，并且产品表将具有将引用具有正确类别条目的类别表中的行的字段(可能称为“category_id”)。这有几个好处，包括不重复的数据。
这也意味着，如果您拼写类别名称，例如，您可以更新类别表，然后它是固定的，因为这是唯一的值存在的地方。
但在文档数据库中，这不是它的工作原理。你完全反规范化，这意味着在“产品”文档中，你实际上会有一个包含实际类别字符串的值，导致大量的数据重复，并且错误更难以纠正。考虑这更多，不是也意味着运行查询像“给我所有产品这个类别”可能导致结果没有完整性。
当然，这方面的方法是重新实现文档数据库中的整个“category_id”事情，但是当我到达这一点在我的想法，我意识到我应该留在关系数据库，而不是重新实现它们。
这使我相信我缺少一些关键的文档数据库，导致我走这条不正确的路径。所以我想把它堆栈溢出，我错过了什么？
You completely denormalize,meaning in the “products” document,you would actually have a value holding the actual category string,leading to lots of repetition of data […]
真，反规范意味着存储附加数据。它还意味着更少的集合(sql中的表)，从而导致数据片段之间的关系较少。每个单个文档可以包含否则将来自多个sql表的信息。
现在，如果您的数据库分布在多个服务器上，查询单个服务器而不是多个服务器更有效率。使用文档数据库的非规范化结构，更有可能您只需要查询单个服务器以获取所需的所有数据。使用sql数据库，有可能您的相关数据分布在多个服务器上，使查询效率低下。
[…] and errors are much more difficult to correct.
也是真的。大多数Nosql解决方案不保证诸如参照完整性之类的事物，这是sql数据库常见的。因此，您的应用程序负责维护数据之间的关系。然而，因为文档数据库中的关系量非常小，所以它不会听起来那么难。
文档数据库的一个优点是它是无模式的。您可以随时定义文档的内容;您不会像使用sql数据库那样绑定到预定义的一组表和列。
现实世界的例子
如果您在sql数据库之上构建CMS，则可以为每个CMS内容类型分别创建一个表，也可以为具有通用列的单个表存储所有类型的内容。使用单独的表，你会有很多表。只要考虑所有的连接表，你需要为每个内容类型的标签和注释。使用单个通用表，您的应用程序负责正确管理所有数据。此外，您的数据库中的原始数据很难更新，在CMS应用程序之外是毫无意义的。
使用文档数据库，您可以将每种类型的CMS内容存储在单个集合中，同时在每个文档中保持强烈定义的结构。您还可以在文档中存储所有标签和注释，使数据检索非常高效。这种效率和灵活性有一个代价：您的应用程序更负责管理数据的完整性。另一方面，与sql数据库相比，使用文档数据库扩展的价格要低得多。
建议
正如你所看到的，sql和Nosql解决方案都有优点和缺点。作为大卫already pointed out，每种类型都有它的用途。我建议您分析您的需求并创建两个数据模型，一个用于sql解决方案，一个用于文档数据库。然后选择最适合的解决方案，保持可扩展性。