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

Question

我一直是reading a lot 的best practices 以及我应该如何embrace the _id。老实说，如果我在开始扩展我的应用程序时不这样做，我可能会面临这样的后果，这让我有点偏执。

目前每个数据库大约有 50k 个文档。仅仅几个月的大量使用。我希望这会增长很多。我做了很多.find()Mango Queries，索引不多；老实说，处理关系风格的文档结构。

例如：

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

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

由于日程安排变得非常紧张，我目前处于无法返回的状态。如果我想改变我现在做事的方式，最好的时机是在它变得太疯狂之前。

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

能够像这样使用 _all_docs 抓取功能拨打一个电话对我来说很有吸引力：

{
  "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)}。这产生的索引将允许您在查询视图时明智地使用start_key&end_key，通过已知的project_id 获取文档。见Introduction to views
3. 正如您所说，将更多信息打包到 _id 字段中可以让您在 _all_docs 端点上执行范围查询。

如果您选择以下关键设计：

project{project_id}:signature{kuuid}

那么数据库的主索引将单个项目的所有文档组合在一起。将 project_id 放在 ':' 字符之前是为即将推出的称为“分区数据库”的 CouchDB 功能做准备，该功能将逻辑相关的文档分组到自己的分区中，从而可以更快、更轻松地对单个文件执行查询分区，在您的情况下是一个项目。这个功能还没有准备好，但它可能有一个{partition_key}:{document_key} 格式的_id 字段，所以让你的文档_ids 为它做好准备是没有害处的（参见CouchDB mailing list！同时， _all_docs 上的范围查询将起作用。