couchdb - 在 CouchDB 中，我应该将 _id 用于关系和 _changes 吗？

Question

我去过reading a lot的 best practices我应该怎么做embrace the _id .老实说，如果我在开始扩展我的应用程序时不这样做，我可能会面临的后果有点偏执。

目前我每个数据库有大约 50k 个文档。这只是几个月的大量使用。我希望这会增长很多。我做了很多 .find() Mango 查询，没有太多索引；老实说，处理关系样式的文档结构。

例如:

• 首先从 ID 获取项目。
• 然后进行查找查询:
  • 获取所有 type:signature，其中 project_id: X。
  • 获取所有 type:revisions，其中 project_id: X。

这样做的原因是我非常努力地不更新文档。这些文档中有很多都是离线创建的，因此一次编写的工作流程对我来说非常重要，可以避免冲突。

由于日程安排变得非常紧张，我目前正处于无法回头的地步。如果我想改变我做事的方式，现在是在事情变得太疯狂之前的最佳时机。

我很想听听您对使用 _id 进行数据结构化的想法以及人们的想法。

能够像这样用 _all_docs grab 调用一个电话听起来很吸引我:

{
  "include_docs": true,
  "startkey": "project:{ID}",
  "endkey": "project:{ID}:\ufff0"
}

我的文档的一种类型的设置示例如下:

主文档

{
    _id: {COUCH_GENERATED_1},
    type: "project",
    ..
    .
}

签名文件

{
    _id: {COUCH_GENERATED_2},
    type: "signature",
    project_id: {COUCH_GENERATED_1},
    created_at: {UNIX_TIMESTAMP}
}

对主文档的更改

{
    _id: {COUCH_GENERATED_3},
    type: "revision",
    project_id: {COUCH_GENERATED_1},
    created_at: {UNIX_TIMESTAMP}
    data: [{..}]
}

---

我在想我是否应该做这样的事情:

主文档:_id: project:{kuuid_1}

签名文件:_id: project:{kuuid_1}:signature:{kuuid_2}

对主文档的更改:_id: project:{kuuid_1}:rev:{kuuid_3}

我只是想以一种将来不会打扰我的方式来设置我的数据库。我知道会出现问题，但如果可以避免的话，我不想对结构进行大量更改。

我想到这个的另一个原因是我在我的数据库中观察 _changes 并且能够知道正在发生的类型，而无需在每次文档更改时都获取每个文档听起来也很吸引人。

Answer 1

设置您的数据库结构，使数据检索更容易是一种很好的做法。在我看来你有一些选择:

1. 如果感兴趣的文档中有一个名为 project_id 的字段，您可以在 project_id 上创建一个索引，这样您就可以获取与已知 project_id 相关的所有文档便宜。见CouchDB Find
2. 创建一个以 project_id 为键的 MapReduce 索引，例如 if (doc.project_id) { emit(doc.project_id)}。这产生的索引将允许您通过已知的 project_id 获取文档，并在查询 View 时明智地使用 start_key 和 end_key。见Introduction to views
3. 如您所说，将更多信息打包到 _id 字段允许您在 _all_docs 端点上执行范围查询。

如果您选择的按键设计为:

project{project_id}:signature{kuuid}

然后数据库的主索引将单个项目的所有文档组合在一起。将 project_id 放在 ':' 字符之前是为即将推出的名为“分区数据库”的 CouchDB 功能做准备，该功能将逻辑上相关的文档分组到它们自己的分区中，从而可以更快更轻松地对单个文档执行查询分区，在你的情况下是一个项目。此功能尚未准备就绪，但它可能具有 _id 字段的 {partition_key}:{document_key} 格式，因此准备好文档 _ids 没有坏处对于它何时着陆(请参阅 CouchDB mailing list !与此同时，对 _all_docs 的范围查询将起作用。