use*_*427 69 database couchdb relational-database nosql document-database
我一直试图看看我是否可以用基于文档的数据库来完成一些要求,在本例中是CouchDB.两个通用要求:
我开始认为基于文档的数据库不是满足这些要求的最佳选择.此外,我无法想象使用基于文档的数据库(也许我的想象力太有限).
当我尝试使用面向文档的数据库来满足这些要求时,你能解释一下我是否向榆树询问梨子吗？
Ker*_*err 34
您需要考虑如何以面向文档的方式处理应用程序.如果您只是尝试复制如何在RDBMS中建模问题,那么您将失败.您可能还想做出不同的权衡.([编辑:不确定这与参数有什么关系,但是:]请记住,CouchDB的设计假定您将拥有一个可能在任何时间失败的许多节点的活动集群.您的应用程序如何处理其中一个数据库节点从中消失在它下面？)
考虑它的一种方法是想象你没有任何计算机,只有纸质文件.如何使用传递的纸张创建有效的业务流程？你怎么能避免瓶颈？如果出现问题怎么办？
你应该考虑的另一个角度是最终的一致性,你最终会进入一致的状态,但是你可能会在一段时间内不一致.这在RDBMS领域是一种诅咒,但在现实世界中极为常见.规范交易的例子是从银行账户转账.这实际上是如何在现实世界中发生的 - 通过单一的原子交易或通过不同的银行相互发出信用卡和借记通知？写支票时会发生什么？
那么让我们来看看你的例子:
如果我在CouchDB术语中正确理解这一点,您希望拥有一组文档,其中某些命名值保证在所有这些文档中是唯一的？这种情况通常不受支持,因为可以在不同的副本上创建文档.
因此,我们需要查看现实世界的问题,看看我们是否可以对其进行建模.你真的需要它们独一无二吗？您的应用程序可以处理具有相同值的多个文档吗？您需要分配唯一标识符吗？你能确定地做到这一点吗？需要这种情况的常见方案是您需要唯一的顺序标识符.在复制环境中很难解决这个问题.实际上,如果要求唯一ID在时间上严格按顺序创建,那么如果您需要直接使用id,则不可能.你需要放松至少其中一个限制.
我不知道在这里添加什么,因为你在该帖子上发表的最后一条评论是"非常有用!谢谢".那里概述的方法是否有什么遗漏仍然会导致您出现问题？我认为库尔特先生的答案非常充实,我添加了一些可以减少争用的增强功能.
dac*_*cot 13
是否需要规范化数据？
我在同一条船上,此刻我很喜欢couchdb,我认为整个功能风格很棒.但是,我们确实开始在欧内斯特的应用程序中使用它们.我的意思是,是的,我们都可以非常快速地开始开发应用程序,所有那些关于正常形式的令人讨厌的问题被搁置在路边并且不使用模式.但是,用一句话"我们站在巨人的肩膀上".有充分的理由使用RDBMS并规范化和使用模式.我的老甲骨文正在思索没有形式的数据.
我在couchdb上的主要惊喜因素是复制内容和版本控制系统协同工作.
上个月我一直在绞尽脑汁试图弄清楚couchdb的存储机制,显然它使用B树但不存储基于正常形式的数据.这是否意味着它真的非常聪明并且意识到复制了一些数据,所以我们只需要指向这个B树条目？
到目前为止,我正在考虑将xml文档,配置文件,流式传输到base64字符串的资源文件.
但是我会使用couchdb来获取结构数据.我不知道,任何帮助都非常感谢.
可能对存储RDF数据甚至是自由格式文本很有用.
一种可能性是拥有一个主要的关系数据库，用于存储可以通过其 ID 检索的项目的定义，以及一个用于这些项目的描述和/或规范的文档数据库。例如，您可以拥有一个具有以下字段的 Products 表的关系数据库：
并且该规范字段实际上将包含对具有产品技术规范的文档的引用。这样，您就可以两全其美。
基于文档的数据库最适合存储文档。Lotus Notes 是一种常见的实现，Notes 电子邮件就是一个示例。对于您所描述的电子商务、CRUD 等，关系数据库更适合存储和检索索引的数据项/元素（而不是文档）。