CouchDB - 人类可读的 id

Question

我将 CouchDB 与 node.js 一起使用。现在只涉及一个节点，即使在遥远的未来，它也不打算改变它。虽然我可以删除大多数需要短且类似自动增量（它可以是稀疏但不像随机）ID 的情况，但仍然有一个地方用户实际需要输入产品的 ID。我想保持这个 ID 尽可能短，并且采用比“4ab234acde242349b”之类的更易于阅读的格式，因为有时必须手动输入等等。

然而，在数据库中，它可以用 CouchDB 喜欢的任何 ID 存储（使用默认的自动生成的 UUID），但应该可以给它一个可以用来识别它的数字。我想到的是创建一个包含 CouchDB 中所有 UUID 的数组的文档。在节点中创建新产品时，我将运行一个更新处理程序，该处理程序最后使用新的唯一 ID 更新所述文档。为了获得产品 ID，我将使用 indexOf 查询数组和客户端，我可以将索引作为短 ID。

我不知道这是否可行。从性能的角度来看，我可以说以下几点：应该执行数字 ID -> uuid 的查询比 uuid -> 数字 ID 的查询要多。数据库中每年最多有 7000 个新条目。也没有可以删除产品的用例，但我不想依赖它。

是否有任何其他适用的方法来生成可以与我的文档关联的更短且更易于阅读的 ID？

/编辑 从技术角度来看：它似乎正在工作。我可以同时进行数字 uuid 的转换，而且看起来很顺利。我现在不知道这是否适用于复制和其他东西，但正如所说的数组，我猜它应该，对吧？

Answer 1

你有两个选择：

1. 将您的人类可读 id 设置为 _id 字段。基本上你可以在创建文档中设置对 DB 的调用，它会接受它。这可能是一个更轻量级的解决方案，但它有一些限制：

   1. 它必须是唯一的。您还应该小心客户端尝试创建文档，而是覆盖现有文档。
   2. 它只能包含字母数字或几个特殊字符。根据我的经验，拥有额外的字符类型是自找麻烦。
   3. 它不能超过理论上的字符串长度限制（Couchdb 没有定义，但您应该这样做）。 Long ids will increase your views(indexes) size really bad。 And it might make it s lower。

   如果这些事情对你来说都没有问题，那么你应该使用这个解决方案。

2. 正如您自己所说，让_id 成为 UUID，并将人类可读的 id 设置为另一个字段。要通过人类可读的 id 访问文档，您只需创建一个 view 发出人类可读的 id 作为键，然后将文档作为值发出或通过 include_docs=true 选项获取文档。每当到达视图时，Couchdb 将逐步更新视图并返回列表。这与您创建一个包含 id 数组/对象的文档实际上是一样的。除了使用 couchdb 视图，您可以获得更高的性能。

   这在查询和插入时也可能会稍微慢一些。如果id是按顺序插入的，没关系，如果不是，CouchDB will slightly take more time to insert it at the right place。这些不适用于数据库中的大量插入。

   查询时间不应超过第一个选项的总查询时间的 10% 以上。我认为 10% 确实是一个很大的数字。它很可能会低于 5%，我记得在我的 CouchDB 应用程序中，我从按 _id 读取切换到按键读取视图，当在同时，它并不明显。

   这是人们在用户登录时通过 id 以外的字段查询文档的方式，例如使用电子邮件查询用户文档。

如果您不知道 couchdb 视图的工作原理，您应该阅读 views chapter 的 couchdb definite guide book。

还要确保您远离其中包含大量数组的文档。我认为 CouchDB，每个文档有 4GB 的限制。我记得有很多文档，而且查询时间很长，因为视图必须迭代每个数组项。最后，我为每个数组项创建了一个文档。它的速度要快得多。