我真的很想了解NoSQL方法，但有些方面让我感到困惑。而最容易突出的文档似乎并没有解决它们（到目前为止我已经发现）。
例如，我正在查看the CouchDB website ...
自包含数据
发票包含有关卖家，买家，日期以及所售商品或服务列表的单笔交易的所有相关信息。 [...]自成一体的文件，在这篇论文中没有抽象的参考文献，指出了其他一些带有卖家姓名和地址的文件。会计师很欣赏将所有内容整合到一起的简单性地点。如果有这个选择，程序员也会对此表示赞赏。
通过“一个抽象参考”，我认为它们意味着FK，对吧？在一个类似的SQL DB中，“另一张纸”将成为sellers表中的一行？
好的，但是当发现有人搞砸了，卖家的地址实际上是枫树大道而不是Maple Lane时会发生什么事情而且你有46,487张发票就像Maple Lane那样。
正统的NoSQL处理这种必然性的方法是什么？
您是否使用“Lane”扫描了您的480万张发票“文件”中的96k，将它们挖空并执行96k写入？
如果是这样，在这个描述的基于CouchDB的应用程序中，WHO会进入并执行该操作？因为，在这里猜测，但我想你的前端可能没有卖家表格的观点。因为你的卖家都藏在发票里面，对吧？所以在NoSQL中，这种数据校正和维护成为DBA的工作？
（另外，您是否真的在涉及该卖家的每张发票上重复所有卖家的信息？这不是很贵吗？）
在庞大而繁忙的系统中，您如何确保所有重复的卖家数据都是正确且一致的？
我正在考虑针对一系列即将推出的项目寻找哪种存储技术。 NoSQL显然非常受欢迎并被广泛采用。在某些领域，它是“黄金之路”/默认选择。如果我想将PostgreSQL与Node.js一起使用，我将不得不寻找有关不太受欢迎的库和支持的信息。
因此，对MongoDB，CouchDB等存在重大的现实压力。
然而，在我正在设计的系统中，我上面提到的问题真的很重要。是否有一种经过验证，建立和实用的方法来解决这些问题？
答案 0 :(得分：1)
正统的NoSQL处理这种必然性的方法是什么？
两种可能的方法：
基本上与pre-SQL（即纸质文件柜）方式相同：
历史发票将继续有错误的数据。但这没关系，可以说甚至比RDBMS方式更好，因为它准确地反映了历史。
转到更新所有受影响文档的额外工作。使用正确构建的索引或视图，这并不难（您不必扫描所有480万张发票 - 您的视图将引导您实际受到更改影响的18个）
我想你的前端可能没有卖家表格的观点。
为什么不呢？如果您使用基于卖家的查询，我确定希望您有基于卖家的视图（或多个）。
因为您的卖家都嵌入发票中，对吗？
这无关紧要。视图可以索引数据的任何部分。
您是否真的在涉及该卖家的每张发票上重复所有卖家的信息？
当然。每次在纸上打印发票时都会重复一遍，对吗？您的数据库文档是＆＃34;文档＆＃34;，与打印的发票相同。
不是很贵吗？
如果您将整个数据库存储在手机上，也许吧。否则，硬盘现在很便宜。
然而，在我设计的系统中，我上面提到的问题确实很重要。
NoSQL对每项工作都不合适。如果交易完整性很重要（并且它可能适用于您似乎正在讨论的财务应用程序），那么它可能不是正确的工具。
将CouchDB视为同步协议，并附带数据库，以求好运。
如果您的核心功能是同步功能，那么CouchDB可能非常适合。如果这不是您的应用程序的功能核心，那么它可能是错误的工具。