Azure Cosmos DB Update Pattern
我最近开始在一个项目中使用Cosmos DB，我遇到了一些设计问题。来自SQL的背景，我理解相关数据应该嵌套在非关系型数据库DB的文档中。这确实意味着文档可能会变得相当大。
由于不支持部分更新，当您想更新文档上的单个属性时，要实现的最佳设计模式是什么？
为了执行更新，我应该读取整个文档服务器端，更新值并立即写回文档吗？如果文档很大(如果所有数据都是嵌套的，这是不可避免的),这似乎会有问题。
如果我采用制作许多较小文档的方法并根据ID推断关系，我认为这将极大地解决更新问题的读/写问题，但感觉我正在违背非关系型数据库的概念，本质上我正在构建关系数据库。
谢谢
共有3个答案
嵌入或引用是我在非关系型数据库中设计文档结构时最常见的问题。
在嵌入关系中，子实体已经嵌入到父文档中。在引用关系中，单独文档中的子实体和另一个文档中的父实体，基本上有两种（或多种）类型的文档。
没有一种关系模式适合所有人。应采用的方法取决于要对正在设计的数据执行的检索和更新。
1.是否需要检索所有子实体以及父实体？如果是，则使用嵌入关系。
您的用例2.Do允许单独检索实体？本例使用关系模式。
我工作过的大多数用例，我使用的是关系模式。例如:社交图(带有关系树的档案)，邻近点(基于GeoJSON的邻近搜索)，分类列表等。
关系模式也更容易更新和维护，因为实体存储在各个文档中。
每当您尝试创建文档时，请尝试考虑以下几点：
>
文档的部分是否需要单独访问。如果是，则创建引用文档；如果否，则创建嵌入文档。
如果你想知道该选择什么，我认为你应该看看这个问题：它适用于MongoDb，但会帮助你嵌入和引用文档
锁定和闩锁。如果部分更新成为可能，这就是需要发生的事情。这是一个工程难题
如果文档很大，这似乎是有问题的，如果您的所有数据都嵌套，它们不可避免地会很大。
定义您的恐惧燃烧请求单元、应用程序主机内存和进出网络流量？你认为这是一个问题，但你没有说明具体的结果。我并不是说你错了，也不是怀疑部分更新方法的效率，我只是说论点很薄弱。
通常您希望JOIN在非关系型数据库中没有任何内容，因此我完全同意您的最后一段。