Azure cosmosdb 使用NoSQL数据库存储值集列表的最佳实践

我正在开发一个使用NoSQL后端的解决方案。我的经验是传统上使用关系数据库，我想讨论存储可能出现在UI下拉列表中的值列表的最佳方式。传统上，我只需在关系数据库中创建一个表来存储这一小组值，然后我的记录将绑定到表示该值的特定id。一个简单的例子是一个Person表，其中包含我的所有Person记录，以及一个包含所有可能头发颜色的值的头发颜色列表。对于每个人，该头发颜色值列表表中的头发颜色id将存储在person记录中。所以是传统的外键关系

大多数下拉列表都不是很大，它们都是小集合（10个字段），因此将它们存储在宇宙中自己的容器中似乎有些过分。我想我还可以在API模型中将这些值设置为常量，并以这种方式管理这些值。但是，如果这些值发生更改，我需要重新构建API以公开这些值

关于如何处理NoSQL空间的最佳实践，您有什么想法吗？在NoSQL后端创建一个包含值列表的容器，将值作为常量存储在我的API模型中还是其他什么

---

感谢您花时间考虑这个问题。

在这些场景中，对于UI元素的参考数据，我通常建议将所有这些数据存储在单个Cosmos容器中。Cosmos是模式不可知的，因此您可以混合/匹配不同的数据模式。如果数据是有限的，那么CosmosDB中的小集合的开销已经通过数据库级资源调配得到了一定程度的缓解，但我仍然不会有很多微集合（IIRC每个集合的最小RU仍然是100）。它是什么类型的应用程序？e、 对于一个繁忙的网站，你可能不想在用户每次加载带有下拉菜单的页面时都点击Cosmos，所以可以考虑使用Redis之类的缓存（也可以提供持久性）。注意：

个人

文档本身应该是全发色的，而不是发色的。非常感谢您对微收藏的深入了解。在person集合中存储值（如头发颜色）和存储ID之间的界限在哪里？还是应该永远是价值？