blocks|key|3422706|text|你的问题有点主观，因为你要求的是实体设计，对此，没有一个正确的答案。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3422707|但是:从更客观的角度来看:没有什么可以阻止您在集合中拥有多个实体类型(例如，Company文档类型和Employee文档类型，在您的例子中)。|offset|length|style|CODE|3422708|您需要自己包含某种类型的提示(可能是type属性)，以帮助在运行查询时区分这两种提示。但是，通过将这两种类型都包含在同一个集合中，现在可以在其中使用集合范围。关于type属性:由于DocumentDB默认对所有属性进行索引，所以type属性很容易集成到查询中。|3422709|编辑删除了大约3集每容量单位的部分，因为当DocumentDB从预览转移到生产时，这种安排就被删除了。|BOLD|3422710|entityMap^0|0|12|7|1E|8|0|I|4|29|4|36|4|0|0|2|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@$D|Q|E|R|F|G]|$D|S|E|T|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|U|8|@$D|V|E|W|F|G]|$D|X|E|Y|F|G]|$D|Z|E|10|F|G]]|9|@]|A|$]]|$1|J|3|K|5|6|7|11|8|@$D|12|E|13|F|L]]|9|@]|A|$]]|$1|M|3|-4|5|6|7|14|8|@]|9|@]|A|$]]]|N|$]]

Your question is a bit subjective, as you're asking for entity design, and for that, there's no single right answer.

However: From a more objective standpoint: There's nothing stopping you from having multiple entity types within a collection (e.g. <code>Company</code> document type and <code>Employee</code> document type, in your case).

You'd need to include some type of hint for yourself (maybe a <code>type</code> property) to help differentiate between the two when running your queries. But, by having both types within the same collection, you now have a collection-scope to work within. Regarding a <code>type</code> property: Since DocumentDB indexes all properties by default, a <code>type</code> property would be easy to integrate into your queries.

EDIT Removed part about 3-collections-per-capacity-unit, as that arrangement was removed when DocumentDB shifted from Preview to Production.

blocks|key|2997384|text|通常情况下，每个集合存储多个实体类型是好的。是否将实体类型存储到单个文档中需要更多的思考。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2997385|正如David提到的，如何对数据进行建模有点主观。|2997386|在集合中存储多个实体类型|offset|length|style|BOLD|2997387|首先..。让我们讨论如何在集合中存储多个实体。DocumentDB集合是而不是表。集合不强制架构；换句话说，可以在同一集合中使用不同的架构存储不同类型的文档。您可以通过向文档中添加类型属性来跟踪不同类型的实体。|2997388|您应该将集合视为执行查询和事务的分区和边界的一个单元。因此，在同一集合中存储不同实体类型的一个巨大好处是，您可以通过sprocs立即获得事务支持。|2997389|在文档中存储多个实体类型|2997390|是否在单个文档中存储多个实体类型需要更多的思考。这通常是指非规范化(通过在单个文档中嵌入数据来捕获数据之间的关系)和规范化(通过创建到o其他文档的弱链接来捕获数据之间的关系)。|2997391|通常，de-normalizing提供更好的读取性能。|2997392|应用程序可能需要较少的查询和更新来完成公共操作。|2997393|通常，在下列情况下使用非规范化数据模型：|2997394|有实体间的“包含”关系|unordered-list-item|2997395|在实体之间有一对一的关系|2997396|非规范化数据变化不频繁。|2997397|没有绑定，非规范化数据将不会增长。|2997398|非规范化数据与文档中的数据是不可缺少的。|2997399|2997400|2997401|非规范化数据模型的示例：|2997402|{
++"Id":+1001,
++"Type":+"Company",
++"Industry":+"Software",
++"Employees":+[
++++{
++++++"Id":+10011,
++++++"Type":+"Employee",
++++++"Name":+"John+Doe"
++++},
++++{
++++++"Id":+10012,
++++++"Type":+"Employee",
++++++"Name":+"Jane+Doe"
++++}
++]
}|code-block|syntax|javascript|2997403|通常，规范化提供更好的写入性能。|2997404|提供比非规范化更灵活的功能。|2997405|客户端应用程序必须发出后续查询才能解析引用。换句话说，规范化的数据模型可能需要更多的往返到服务器。|2997406|通常，使用规范化数据模型：|2997407|当去正常化会导致数据重复，但不会提供足够的读取性能优势，超过复制的含意。|2997408|表示一对多的关系|2997409|代表多到多的关系。|2997410|相关数据频繁变化|2997411|2997412|2997413|规范化数据模型的示例：|2997414|{
++"Id":+1001,
++"Type":+"Company",
++"Industry":+"Software"
}

{
++"Id":+10011,
++"Type":+"Employee",
++"Name":+"John+Doe",
++"CompanyId":+1001
}

{
++"Id":+10012,
++"Type":+"Employee",
++"Name":+"Jane+Doe",
++"CompanyId":+1001
}|2997415|混合逼近|2997416|在正规化和非正常化之间做出选择并不一定是一个黑白的选择。我经常发现，成功的设计模式是一种混合方法，在这种方法中，您可以选择对对象的部分字段集合进行规范化，并对其他字段进行去规范化。|2997417|换句话说，您可以选择去规范化频繁读取的稳定(或不变的)属性，以减少后续查询的需要，而对频繁写入/变异的字段进行规范化，以减少扇出写入的需要。|2997418|混合办法的例子：|2997419|//+Author+documents:
[{
++"id":+1,
++"firstName":+"Thomas",
++"lastName":+"Andersen",
++"countOfBooks":+3,
++"books":+[1,+2,+3],
++"images":+[{
++++"thumbnail":+"http://....png"
++},+{
++++"profile":+"http://....png"
++},+{
++++"large":+"http://....png"
++}]
},+{
++"id":+2,
++"firstName":+"William",
++"lastName":+"Wakefield",
++"countOfBooks":+1,
++"books":+[1,+4,+5],
++"images":+[{
++++"thumbnail":+"http://....png"
++}]
}]

//+Book+documents:
[{
++"id":+1,
++"name":+"DocumentDB+101",
++"authors":+[{
++++"id":+1,
++++"name":+"Thomas+Andersen",
++++"thumbnailUrl":+"http://....png"
++},+{
++++"id":+2,
++++"name":+"William+Wakefield",
++++"thumbnailUrl":+"http://....png"
++}]
},+{
++"id":+2,
++"name":+"DocumentDB+for+RDBMS+Users",
++"authors":+[{
++++"id":+1,
++++"name":+"Thomas+Andersen",
++++"thumbnailUrl":+"http://....png"
++},+]
}]|2997420|entityMap^0|0|0|0|3|0|10|3|0|0|0|3|0|0|3|E|0|0|0|0|0|0|0|0|0|0|0|0|3|3|0|0|0|0|0|0|0|0|0|0|0|0|0|4|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|2F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|2G|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|2H|8|@$F|2I|G|2J|H|I]]|9|@]|A|$]]|$1|J|3|K|5|6|7|2K|8|@$F|2L|G|2M|H|I]]|9|@]|A|$]]|$1|L|3|M|5|6|7|2N|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|2O|8|@$F|2P|G|2Q|H|I]]|9|@]|A|$]]|$1|P|3|Q|5|6|7|2R|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|2S|8|@$F|2T|G|2U|H|I]]|9|@]|A|$]]|$1|T|3|U|5|6|7|2V|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|2W|8|@]|9|@]|A|$]]|$1|X|3|Y|5|Z|7|2X|8|@]|9|@]|A|$]]|$1|10|3|11|5|Z|7|2Y|8|@]|9|@]|A|$]]|$1|12|3|13|5|Z|7|2Z|8|@]|9|@]|A|$]]|$1|14|3|15|5|Z|7|30|8|@]|9|@]|A|$]]|$1|16|3|17|5|Z|7|31|8|@]|9|@]|A|$]]|$1|18|3|-4|5|6|7|32|8|@]|9|@]|A|$]]|$1|19|3|-4|5|6|7|33|8|@]|9|@]|A|$]]|$1|1A|3|1B|5|6|7|34|8|@]|9|@]|A|$]]|$1|1C|3|1D|5|1E|7|35|8|@]|9|@]|A|$1F|1G]]|$1|1H|3|1I|5|6|7|36|8|@$F|37|G|38|H|I]]|9|@]|A|$]]|$1|1J|3|1K|5|6|7|39|8|@]|9|@]|A|$]]|$1|1L|3|1M|5|6|7|3A|8|@]|9|@]|A|$]]|$1|1N|3|1O|5|6|7|3B|8|@]|9|@]|A|$]]|$1|1P|3|1Q|5|Z|7|3C|8|@]|9|@]|A|$]]|$1|1R|3|1S|5|Z|7|3D|8|@]|9|@]|A|$]]|$1|1T|3|1U|5|Z|7|3E|8|@]|9|@]|A|$]]|$1|1V|3|1W|5|Z|7|3F|8|@]|9|@]|A|$]]|$1|1X|3|-4|5|6|7|3G|8|@]|9|@]|A|$]]|$1|1Y|3|-4|5|6|7|3H|8|@]|9|@]|A|$]]|$1|1Z|3|20|5|6|7|3I|8|@]|9|@]|A|$]]|$1|21|3|22|5|1E|7|3J|8|@]|9|@]|A|$1F|1G]]|$1|23|3|24|5|6|7|3K|8|@$F|3L|G|3M|H|I]]|9|@]|A|$]]|$1|25|3|26|5|6|7|3N|8|@]|9|@]|A|$]]|$1|27|3|28|5|6|7|3O|8|@]|9|@]|A|$]]|$1|29|3|2A|5|6|7|3P|8|@]|9|@]|A|$]]|$1|2B|3|2C|5|1E|7|3Q|8|@]|9|@]|A|$1F|1G]]|$1|2D|3|-4|5|6|7|3R|8|@]|9|@]|A|$]]]|2E|$]]

It is generally good to store multiple entity types per collection. Whether to store entity types within to a single document or not takes a bit more thought.

As David mentioned - how to model data is a bit subjective.

Storing Multiples Entity Types within a Collection

First... let's talk about storing multiple entities in a collection. DocumentDB collections are not tables. Collections do not enforce schema; in other words, you can store different types of documents with different schemas in the same collection. You can track different types of entities simply by adding a type attribute to your document.

You should think of Collections as a unit of partition and boundary for the execution of queries and transactions. Thus a huge perk for storing different entity types within the same collection is you get transaction support right out of the box via sprocs.

Storing Multiple Entity Types within a Document

Whether you store multiple entity types within a single document takes a bit more thought. This is commonly referred to de-normalizing (capturing relationships between data by embedding data in a single document) and normalizing (capturing relationships between data by creating weak links to o other documents) your data.

Typically de-normalizing provides better read performance.

The application may need to issue fewer queries and updates to complete common operations.

In general, use de-normalized data models when:

<ul>
<li>have “contains” relationships between entities</li>
<li>have one-to-few relationships between entities </li>
<li>de-normalized data changes infrequently</li>
<li>de-normalized data won’t grow without bound</li>
<li>de-normalized data is integral to data in document</li>
</ul>

Example of a de-normalized data model:

<pre><code>{
 "Id": 1001,
 "Type": "Company",
 "Industry": "Software",
 "Employees": [
 {
 "Id": 10011,
 "Type": "Employee",
 "Name": "John Doe"
 },
 {
 "Id": 10012,
 "Type": "Employee",
 "Name": "Jane Doe"
 }
 ]
}
</code></pre>

Typically normalizing provides better write performance.

Provides more flexibility than de-normalizing

Client-side applications must issue follow-up queries to resolve the references. In other words, normalized data models can require more round trips to the server.

In general, use normalized data models:

<ul>
<li>when de-normalizing would result in duplication of data but would not provide sufficient read performance advantages to outweigh the implications of the duplication.</li>
<li>representing one-to-many relationships</li>
<li>represent many-to-many relationships.</li>
<li>related data changes frequently</li>
</ul>

Example of a normalized data model:

<pre><code>{
 "Id": 1001,
 "Type": "Company",
 "Industry": "Software"
}

{
 "Id": 10011,
 "Type": "Employee",
 "Name": "John Doe",
 "CompanyId": 1001
}

{
 "Id": 10012,
 "Type": "Employee",
 "Name": "Jane Doe",
 "CompanyId": 1001
}
</code></pre>

Hybrid Approaches

Choosing between normalizing and de-normalizing doesn't have to be a black and white choice. I've often found that a winning design pattern is a hybrid approach, in which you may choose to normalize a partial set of an object's fields and de-normalize the others.

In other words, you could choose to de-normalize frequently read stable (or immutable) properties to reduce the need for follow up queries, while normalize frequently written / mutating fields to reduce the need for fanning out writes.

Example of a hybrid approach:

<pre><code>// Author documents:
[{
 "id": 1,
 "firstName": "Thomas",
 "lastName": "Andersen",
 "countOfBooks": 3,
 "books": [1, 2, 3],
 "images": [{
 "thumbnail": "http://....png"
 }, {
 "profile": "http://....png"
 }, {
 "large": "http://....png"
 }]
}, {
 "id": 2,
 "firstName": "William",
 "lastName": "Wakefield",
 "countOfBooks": 1,
 "books": [1, 4, 5],
 "images": [{
 "thumbnail": "http://....png"
 }]
}]

// Book documents:
[{
 "id": 1,
 "name": "DocumentDB 101",
 "authors": [{
 "id": 1,
 "name": "Thomas Andersen",
 "thumbnailUrl": "http://....png"
 }, {
 "id": 2,
 "name": "William Wakefield",
 "thumbnailUrl": "http://....png"
 }]
}, {
 "id": 2,
 "name": "DocumentDB for RDBMS Users",
 "authors": [{
 "id": 1,
 "name": "Thomas Andersen",
 "thumbnailUrl": "http://....png"
 }, ]
}]
</code></pre>

blocks|key|2997482|text|在过去5年中，Cosmos+DB中发生了许多变化，影响数据结构设计的最重要的变化之一是可以创建许多容器并在所有容器之间共享RU。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2997483|在同一个容器中组合多个实体类型仍然很好(集合的新名称)。然而，在2020年，将每个实体类型放在一个单独的容器中也是可以的。|2997484|当然，这取决于您的应用程序的需要，一个非常重要的考虑是您打算如何阅读这些信息。但是，这里有一个通用的数据结构和方法，您可以考虑：|2997485|将每个实体保存在各自的容器中。|ordered-list-item|2997486|包含一个具有实体名称的属性|2997487|以一种方式选择分区键，这样您就不会在一个分区中有超过10+GB的数据。|2997488|确定由于大量调用而需要最佳性能的读取。|2997489|：将数据复制到为预期读取优化的容器|offset|length|style|BOLD|2997490|2997491|2997492|对于要优化的读取，请将数据复制到专门用于该目的的新容器中，并确保分区键与查询的主参数匹配。您可以将许多不同的实体放在同一个容器中。|2997493|这样，您会发现读取操作的效率要高很多倍。|2997494|Cosmos+DB性能在很大程度上取决于数据量，如果您确保您的文档易于通过分区键访问，那么在单个文档中放置大量数据而不是将它们保存在单独的文档中，不会获得任何显著的性能提升。|2997495|示例|2997496|你有两个容器：|2997497|订单|unordered-list-item|2997498|订单-详情|2997499|2997500|2997501|订单由productId划分，订单详细信息由orderId划分。但是，对于显示单个用户订单历史的新功能，不仅要通过userId属性获取订单，而且还要对每个订单进行后续调用，以获取放置在单独分区中的订单详细信息，这需要花费太多的RU。|2997502|幸运的是，这两个文档都包含一个userId属性。您要做的是创建一个新容器(可能称为orders-by-user+)，并将userId属性配置为分区键。然后将所有文档从order-details、orders、和复制到这个容器中。|2997503|现在，您可以通过userId对这个容器进行高效的读取。|2997504|您可以使用Data、基于变更提要的Azure函数进行复制，很快就会有一个内置特性(参见注释)：https://stackoverflow.com/a/64355508/392362|2997505|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/a/64355508/392362^0|0|0|0|0|0|0|0|0|1|0|0|0|0|0|0|0|2|0|0|0|0|0|0|3|9|M|7|1L|6|0|F|6|15|E|1O|6|2B|D|2X|9|0|0|R|0|0|2I|1B|17|0|0^^$0|@$1|2|3|4|5|6|7|1T|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1U|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1V|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|1W|8|@]|9|@]|A|$]]|$1|I|3|J|5|H|7|1X|8|@]|9|@]|A|$]]|$1|K|3|L|5|H|7|1Y|8|@]|9|@]|A|$]]|$1|M|3|N|5|H|7|1Z|8|@]|9|@]|A|$]]|$1|O|3|P|5|H|7|20|8|@$Q|21|R|22|S|T]]|9|@]|A|$]]|$1|U|3|-4|5|6|7|23|8|@]|9|@]|A|$]]|$1|V|3|-4|5|6|7|24|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|25|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|26|8|@]|9|@]|A|$]]|$1|10|3|11|5|6|7|27|8|@]|9|@]|A|$]]|$1|12|3|13|5|6|7|28|8|@$Q|29|R|2A|S|T]]|9|@]|A|$]]|$1|14|3|15|5|6|7|2B|8|@]|9|@]|A|$]]|$1|16|3|17|5|18|7|2C|8|@]|9|@]|A|$]]|$1|19|3|1A|5|18|7|2D|8|@]|9|@]|A|$]]|$1|1B|3|-4|5|6|7|2E|8|@]|9|@]|A|$]]|$1|1C|3|-4|5|6|7|2F|8|@]|9|@]|A|$]]|$1|1D|3|1E|5|6|7|2G|8|@$Q|2H|R|2I|S|T]|$Q|2J|R|2K|S|T]|$Q|2L|R|2M|S|T]]|9|@]|A|$]]|$1|1F|3|1G|5|6|7|2N|8|@$Q|2O|R|2P|S|T]|$Q|2Q|R|2R|S|T]|$Q|2S|R|2T|S|T]|$Q|2U|R|2V|S|T]|$Q|2W|R|2X|S|T]]|9|@]|A|$]]|$1|1H|3|1I|5|6|7|2Y|8|@$Q|2Z|R|30|S|T]]|9|@]|A|$]]|$1|1J|3|1K|5|6|7|31|8|@$Q|32|R|33|S|T]]|9|@$Q|34|R|35|1|36]]|A|$]]|$1|1L|3|-4|5|6|7|37|8|@]|9|@]|A|$]]]|1M|$1N|$5|1O|1P|1Q|A|$1R|1S]]]]

Many things have changed in Cosmos DB in the last 5 years and one of the most significant changes affecting data structure design is the possibility to create many containers and share the RU among all of them.
It is still fine to combine multiple entity types in the same container (new name for collection). However, in the year 2020, it is also fine to put each entity type in a separate container.
Of course it depends on the needs of your application and a very significant consideration is how you intend to read this information. However, here is a general data structure and approach that you can consider:
<ol>
<li>Keep each entity in their own container</li>
<li>Include a property with the name of the entity</li>
<li>Choose partition keys in a way so you will never have more than 10 GB data in one partition</li>
<li>Identify the reads for which you will require optimal performance because of high volume of calls</li>
<li>Here's the kicker: Replicate data to a container optimized for expected reads</li>
</ol>
For those reads you want to optimize, replicate the data to a new container dedicated to that purpose and make sure the partition key matches the main parameter that you query by. You can put many different entities in the same container.
You will find that the read operation is many times more efficient this way.
Cosmos DB performance is largely determined by the volume of the data and if you make sure your documents are easy to reach via partition key, you do not get any significant performance gains by putting a lot of data inside a single document as opposed to keeping them in separate documents.
Example
You have two containers:
<ul>
<li>orders</li>
<li>order-details</li>
</ul>
The orders are partitioned by productId and order details are partitioned by orderId. But for a new feature that shows the order history of a single user, it costs far too many RU, not only to get the orders by the userId property, but especially to make subsequent calls for every order to get the order details that are placed in separate partitions.
Instead, luckily, both documents contain a userId property. What you do is create a new container maybe called orders-by-user and configure the userId property to be partition key. Then replicate all documents from orders and order-details to this container.
You can now make incredibly efficient reads on this container by userId.
You can replicate using Data Factory, Azure Functions based on change feed and soon there will be a built-in feature for this purpose (look in the comments):
<a href="https://stackoverflow.com/a/64355508/392362">https://stackoverflow.com/a/64355508/392362</a>

Should there be one entity per collection in document DB?

Consider I have foreign key relationship in below diagram:
<img src="https://i.stack.imgur.com/HKGPp.png" alt="enter image description here">

Should I create two collections one for employee &amp; other for company. Or should I store them into a single collection?

I read <a href="http://azure.microsoft.com/en-us/documentation/articles/documentdb-resources/">here</a> that in documentdb scope of stored procedures triggers etc are within a collection. So by splitting differetn entities into separate collection I loose out of box functionality.

So wouldn't it be better to dump both the classes as single entity as below:

<pre><code>{
 "Id": 1001,
 "Industry": "Software",
 "Employees": [
 {
 "Id": 10011,
 "Name": "John Doe",
 "CompanyId": 1001
 },
 {
 "Id": 10012,
 "Name": "Jane Doe",
 "CompanyId": 1001
 }
 ]
}
</code></pre>

What is the standard practise of implementing related entities in DocumentDB?

Single or Multiple Entities Per Collection in DocumentDB

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

在DB文档中，每个集合应该有一个实体吗？考虑到我在下图中有外键关系：​我应该创建两个集合，一个用于员工，另一个用于公司。或者我应该把它们储存在一个单一的收藏中？我读过，在documentdb中，存储过程的作用域、触发器等都在集合中。因此，通过将不同的实体分割到单独的集合中，我就失去了开箱即用的功能。因此，最好将这两个类...

问DocumentDB中每个集合的单个或多个实体
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问DocumentDB中每个集合的单个或多个实体EN