问题标签 [document-oriented-db]

我正在使用以下视图函数来迭代数据库中的所有项目（以查找标签），但我认为如果数据集很大，性能会很差。还有其他方法吗？

在工作中，我们最近开始了一个使用 CouchDB（面向文档的数据库）的项目。我一直很难忘记我所有的关系数据库知识。

我想知道你们中的一些人是如何克服这个障碍的？你是如何停止相关性思考并开始记录性思考的（我为编造这个词道歉）。

有什么建议么？有帮助的提示？

编辑：如果有什么不同，我们使用 Ruby 和 CouchPotato 连接到数据库。

编辑 2：SO 让我接受答案。我认为，我选择了最能帮助我学习的那个。但是，我想没有真正的“正确”答案。

我喜欢像 CouchDB 这样的面向文档的数据库的想法。我正在寻找简单的模拟。

我的要求只是：

1. 无模式数据的持久存储；
2. 一些简单的进程内查询；
3. 有事务和版本控制很好；
4. 红宝石API；
5. map/reduce 也不错；
6. 应该在共享主机上工作

我不需要的是 REST/HTTP 接口（我将在进程中使用它）。我也不需要所有可扩展性的东西。

我一定遗漏了一些东西，因为到目前为止我所看到的一切都表明，它并不比一个用于存储 blob 的表和另一个用于适用于它的标签的表更有趣。

现在我当然可以从设计模式中看到一些好处，但是为什么我要使用“面向文档的 DBMS”而不是仅仅使用 SQL Server、Oracle 或 Postgres 等传统数据库来构建它呢？

使用CouchDB，我目前有一个代表一个想法的文档，你可以评价这个想法。每个想法都是一个文件，每个评级都是一个不同的文件。我这样做是为了避免人们在评价一个想法时出现并发访问问题。

我的文件看起来像这样（我已经简化了它们）：

一个想法：

评分：

我目前使用 reduce 函数返回想法 ID 和他/她的评分（评分的简单总和）：

地图：

减少：

我的问题是：我如何将“想法”文档与代表想法评级的减少结果“加入”？

我来自 MySQL 背景，我对面向文档的数据库感兴趣，特别是 CouchDB。我感兴趣的一件事是数据完整性。面向文档的数据库如何处理这个问题？例如，在 RDBMS 中，有一些方法可以防止记录重复，或者保证如果你有一个信息，你就会有另一个，或者根本没有。

我想更广泛地说，我的问题是，与 DODBes 用于解决的问题相比，RDBMS 用于解决哪些类型的问题？我查看了其他一些 stackoverflow 问题以寻求解释，但没有找到任何好的问题。

此外，使用我的数据库，我会做很多报告，包括求和和平均值以及历史趋势。这适合面向文档的数据库吗？

我对面向文档的数据库感兴趣，我想玩 MongoDB。所以我开始了一个相当简单的项目（一个问题跟踪器），但我很难以非关系的方式思考。

我的问题：

1. 我有两个相互关联的对象（例如issue = {code:"asdf-11", title:"asdf", reporter:{username:"qwer", role:"manager"}}- 这里我有一个与问题相关的用户）。我应该创建另一个文档“用户”并通过其 ID 在“问题”文档中引用它（如在关系数据库中），还是应该将所有用户数据留在子文档中？

2. 如果我在文档中有对象（子文档），我可以在一个查询中更新它们吗？

在数据库使用方面，过去十年是 ORM 时代，数百人竞相将我们的对象图保存在普通的老式 RMDBS 中。现在我们似乎正在见证面向文档的数据库时代的到来。这些 数据库针对无模式文档进行了高度优化，但它们的横向扩展和并行查询集群的能力也非常有吸引力。

与 RDBMS 相比，面向文档的数据库在面向对象设计中持久化数据模型方面也具有一些优势。由于表是无模式的，因此可以将属于不同类的对象并排存储在继承层次结构中。此外，随着域模型的变化，只要代码能够处理从旧版本的域类中取回对象，就可以避免每次更改时都必须迁移整个数据库。

另一方面，面向文档的数据库的性能优势主要出现在存储更深的文档时。在面向对象的术语中，由其他类组成的类，例如博客文章及其评论。不过，在我能想到的大多数示例中，例如博客示例，读取访问权限的增加似乎被每次新评论时必须编写整个博客文章“文档”的惩罚所抵消添加。

在我看来，如果一个人非常小心地将对象组织在针对数据读取和写入方式而优化的深度图中，那么面向文档的数据库可以为面向对象系统带来显着的好处，但这意味着了解用例正面。在现实世界中，我们通常不知道，直到我们真正有一个我们可以分析的实时实现。

那么关系数据库与面向文档的数据库的情况是否是一种摇摆和迂回？我对人们的意见和建议很感兴趣，特别是如果有人在面向文档的数据库上构建了任何重要的应用程序。

免责声明：让我知道这个问题是否更适合 serverfault.com

我想存储有关音乐的信息，特别是：

• 流派
• 艺术家
• 专辑
• 歌曲

此信息将在 Web 应用程序中使用，我希望人们能够看到与专辑关联的所有歌曲、与艺术家关联的专辑以及与流派关联的艺术家。

我目前正在使用 MySQL，但在我决定切换之前，我想知道：

1. 水平缩放有多容易？
2. 是否比基于 SQL 的解决方案更易于管理？
3. 我想存储的上述数据会不会太难做无模式？
4. 当我想到关联时，我立即想到 RDBMS；数据可以存储在 CouchDB 之类的东西中，但仍然具有如上所述的某种关联吗？
5. 我的 Web 应用程序需要复制，CouchDB 或其他人如何处理这个？

在使用关系数据库作为我所有的 Windows 编程生命（目前是 .NET）的后端存储之后，我想通过这个 Wikipedia 定义来试验一个面向文档的数据库；它可以是独立的，也可以在现有的非商业数据库系统上分层。

根据您自己的 Windows 编程经验，您会推荐哪种面向文档的开源数据库解决方案？为什么？（开源的原因是为了保持便宜，也因为开源通常非常好并且处于领先地位。）

一个不错的选择是可以与之连接的 .NET 提供程序。

如果一切顺利，最终选择的系统可能会成为一个真正的解决方案。

诚然，这有点主观，可能会引起争论，所以请保持真实，我也会这样做 - 您的答案对于第一次在 Windows 上查看面向文档的数据库的其他人来说将是无价的。我相信你的答案的整体价值将超过任何偏见。

谢谢。