在 cosmosdb 中，我应该使用 id、资源 id 或自链接引用其他文档吗？

Question

我正在设计我的 CosmosDB 集合，并决定我将哪些内容嵌套在一个文档中，哪些内容不会嵌套，等等。但是没有办法解决这个问题 - 在某些情况下，我需要从一个集合中引用另一个集合中的文档。

我看到，在CosmosDB有几种方法来识别文档- id，resource id和self link。它看起来id强制是唯一的，可以由服务器设置或设置为您想要的任何设置。接下来，它看起来resource id总是由服务器自动生成，并且也保证是唯一的。最后，它看起来self link是使用id数据库、集合和文档构建的，这意味着它也是唯一的。我看到三个不同的唯一键，都有自己的用途和语义。

1. 参考其他文档时，我应该在内部使用哪一个？
2. 如何引用不同集合中的文档 - 资源 ID 或自链接是否更像是“通用标识符” id？

Answer 1

• DO使用自然键的id值，如果可能的话。
• DO使用id跨文件的引用。
• 务必为集合/数据库引用使用名称。
• 不使用_rid或_selflink当你需要一个可靠的长期参考。

为什么不使用_rid/ selflink？

• _rid- Comsos DB 内部存储中系统分配的身份。只要文档在存储中不移动，它的值就是稳定的，但只要在存储中重新创建文档，它就会改变。
• _selflink- 系统分配的身份类似于_rid，但除此之外_rid还包括 Cosmos DB 数据库和文档所在集合的类似资源子键。因此它是从帐户级别对文档的引用。

首先，最有可能_rid/_selflink有可能稍微提高性能，因为它们更接近实际数据。尽管在 99% 的情况下，它应该可以忽略不计。

不利的一面是，无论出于何种原因移动文档时，_rid/_selflink 都会发生变化。例如，：

• 备份还原
• 删除文档并使用完全相同的数据重新创建它
• 重命名 Cosmos DB 数据库/集合（目前通过创建新的和移动的数据来实现）
• 重新创建集合以获得一些不适用于现有集合的新功能
• 通过移动文档类型来重构集合结构（出于业务/性能或安全考虑）

如果发生这种情况，您将很难从数据文档中发现和修复所有引用。哎哟。假设您有大量文档和非平凡模型，这将是脆弱而繁琐的。

此外，如果您查看 Microsoft API 客户端（例如，C# 客户端），那么现在的舒适路径是使用数据库/集合名称和ids。不要打它。你只会让你的代码更丑，你的生活比预期的更艰难。

不过，将它们用于临时临时身份是可以的。

为什么id？

id 是用户分配给一个文档的键，在一个分区内保证唯一性。

• 它针对 API 中的检索进行了优化，性能方面 = 开发速度更快，性能更好。
• 可以将其设置为自然键 - 人类可读且对业务有意义，而无需加载参考文档。= 更少的查找、更少的混淆、更少的 RU/s。
• 它是用户数据的一部分，并且在您四处移动文档时永远不会改变 = 可预测的行为，在灾难恢复期间更少的意外。

唯一需要注意的是，与用户给定的身份一样，您必须稍微计划一下，以确保身份范围确实足以满足您的需求。您的应用程序始终可以设置更严格的唯一性属性（尽管 Cosmos DB 不会强制执行这些属性），或者如果您需要最终的唯一性，则使用 Guids。

容器呢？

相同的参数适用于容器/数据库。

Answer 2

id仅在文档分区内是唯一的。id只要它们具有不同的分区键值，您就可以拥有任意多个相同的文档。

它_rid确实是唯一的，并且是识别文档的最佳形式。如果您的集合已分区，您可以通过使用id并提供分区键值来实现相同的目的。

有两种不同类型的直接读取文档而不查询文档的方式。

• 使用它的自我链接，看起来像这样dbs/db_resourceid/colls/coll_resourceid/documents/doc_resourceid并使用_rid值
• 使用它的替代链接，看起来像这样，dbs/db_id/colls/coll_id/documents/doc_id它使用id

您可以使用的最安全的文档标识形式是使用 s 的形式_rid。

在你的两个问题中，你应该使用自我链接。