我一直在尝试看看是否可以使用基于文档的数据库(在本例中为 CouchDB)来满足某些要求。两个通用要求:
- 具有某些字段的实体的 CRUD，这些字段上有唯一索引
- eBay 等电子商务网络应用 (better description here)。
而且我开始认为基于文档的数据库并不是满足这些要求的最佳选择。此外，我无法想象基于文档的数据库的用途(也许我的想象力太有限)。
当我尝试使用面向文档的数据库来满足这些要求时，如果我是在问榆树上的梨，您能解释一下吗？
最佳答案
您需要考虑如何以面向文档的方式处理应用程序。如果您只是尝试复制您将如何在 RDBMS 中对问题建模，那么您将失败。您可能还需要做出不同的权衡。 ([编辑:不确定这与论点有什么关系但是:] 请记住，CouchDB 的设计假设您将拥有一个由许多节点组成的事件集群，这些节点可能随时发生故障。您的应用程序将如何处理其中一个数据库节点从中消失在它下面？)
一种思考方式是想象您没有任何计算机，只有纸质文档。您将如何使用传递的纸片创建高效的业务流程？如何避免瓶颈？如果出现问题怎么办？
你应该考虑的另一个角度是最终一致性，你最终会进入一致状态，但你可能会在一段时间内不一致。这在 RDBMS 领域是令人厌恶的，但在现实世界中却极为普遍。典型的交易示例是从银行账户转账。这在现实世界中实际上是如何发生的——通过单个原子交易或通过不同的银行相互发布信用和借记通知？写支票时会发生什么？
那么让我们看看你的例子:
- 实体的 CRUD，其中某些字段带有唯一索引。
如果我对 CouchDB 术语的理解是正确的，那么您想要一个文档集合，其中保证某些命名值在所有这些文档中是唯一的？这种情况通常不受支持，因为文档可能是在不同的副本上创建的。
所以我们需要看看现实世界的问题，看看我们是否可以对其进行建模。你真的需要它们是独一无二的吗？您的应用程序可以处理具有相同值的多个文档吗？您需要分配唯一标识符吗？你能确定性地做到这一点吗？需要这样做的常见场景是您需要唯一的顺序标识符。这在复制环境中很难解决。事实上，如果要求唯一 ID 严格按创建时间顺序排列，如果您立即需要该 ID 是不可能的。您至少需要放宽其中一项限制。
- ecommerce 网络应用，例如 ebay
我不确定要在此处添加什么，因为您对该帖子的最后评论是说“非常有用!谢谢”。那里概述的方法中是否遗漏了一些仍然给您带来问题的东西？我认为 MrKurt 的回答非常完整，因此我添加了一些可以减少争用的增强功能。
关于database - 基于文档的数据库与关系数据库的优缺点，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/337344/