PouchDB / CouchDB 中 _id 的最佳实践答案

【问题标题】：Best practices for _id in PouchDB / CouchDBPouchDB / CouchDB 中 _id 的最佳实践
【发布时间】：2017-07-17 08:19:03
【问题描述】：

TL;DR：如果选择在文档的_id 中使用address 和lastname 之类的字段，您如何处理对address 和lastname 的更新？在多设备、有时是离线环境中扩展。

我正在寻找使用文档_id 中将来可能会更改的字段的最佳做法。例如，address 和/或 lastname。不仅客户的地址可以更改，而且如果用户错误地输入了错误的地址怎么办？如果在文档被跨设备复制并在多个设备上更新之后才发现错误怎么办？

有没有办法处理对_ids 的更新？例如，使用新的_id 创建一个全新的文档并删除旧文档？但这是否可以在多设备、有时是离线世界中扩展？

例如：

{
  "_id": "Jane-Smith",
  "address": "44 street, Boston, MA 93999",
  "telephone": "8888888888"
}

要处理有多个同名客户的情况，在客户名称中添加一些东西是否有意义？

{
  "_id": "Jane-Smith-7ae78c",
  "address": "44 street, Boston, MA 93999",
  "telephone": "8888888888"
}

优点：

缺点：

更新：

这篇文章很有帮助：

我没有意识到_ids 可以由address 和 lastname 组成。 但是，如果客户的地址和/或姓名发生变化怎么办？

我正在尝试以正确的方式将 customer 数据存储在 PouchDB / CouchDB 中。

【问题讨论】：

是否有必要在_id 中使用adress 或lastname 等字段？为什么不只使用 GUID？正如您提到的，这应该可以防止冲突和更改值。节省空间和提高性能很重要，但请记住，过早的优化是万恶之源。
这正是我的问题。我目前倾向于使用默认的 GUID 方法。但是，我也很好奇在 _ids 中使用可能随时间变化的字段是否被认为是一种好习惯。

【解决方案1】：

如果您的 id 包含经常更改的信息，那么最好不要将该信息存储在 id 中。将尽可能多的用户信息打包到 id 中的优化是一个很好的优化，但是如果该信息发生变化，它就会崩溃，因为一旦 id 发生变化，您就无法再真正跟踪对该文档的更改，因为它实际上变成了一个新文档.

在您的情况下，您可能应该将 id 设为其他内容（随机、偶数），然后使用 mapreduce/pouchdb-find 进行查询。

【讨论】：