单个或多个实体每收集在DocumentDB [英] Single or Multiple Entities Per Collection in DocumentDB

问题描述

如果有收集每一个实体在文件DB？

Should there be one entity per collection in document DB?

考虑我有如下图外键关系：

Consider I have foreign key relationship in below diagram:

我应该建立两个集合一个员工和放大器;其他的公司。或者我应该将它们存储到一个单一的集合？

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

我看了这里在documentdb范围存储程序触发器等是一个集合中。因此，通过拆分differetn实体为单独收集我失去了盒功能。

I read here 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:

{
  "Id": 1001,
  "Industry": "Software",
  "Employees": [
    {
      "Id": 10011,
      "Name": "John Doe",
      "CompanyId": 1001
    },
    {
      "Id": 10012,
      "Name": "Jane Doe",
      "CompanyId": 1001
    }
  ]
}

什么是DocumentDB实施相关实体的标准做法？

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

推荐答案

这总体上是好的存储每收集多个实体类型。是否存储在单个文件实体类型或不是需要多一点的想法。

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.

内存储倍数实体类型集合

首先...让我们来谈谈在集合中存储多个实体。 DocumentDB馆藏的不可以表。收藏不强制模式;换句话说，你可以存储不同类型的具有相同集合在不同的模式文档。你可以简单地通过添加的键入的属性到您的文档跟踪不同类型的实体。

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.

中存储多个实体类型文档

无论您在单个文档中的多个实体类型需要一些更多的思考。这就是通常所说的去正火的（捕获由一个单一的文档中嵌入数据数据之间的关系）和正火的（通过创建的薄弱环节采集数据之间的关系的邻其他文件）的数据。

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:

• 有的包含的实体之间的关系


• 有无的一对几的实体之间的关系


• 反规范化数据的很少变化的


• 反规范化数据的不会增长的无限制


• 反规范化数据的积分的对文档数据

• have "contains" relationships between entities
• have one-to-few relationships between entities
• de-normalized data changes infrequently
• de-normalized data won’t grow without bound
• de-normalized data is integral to data in document

一反规范化的数据模型的例子：

Example of a de-normalized data model:

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

通常正火提供了更好的写的性能。

提供更大的灵活性比去正火

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:

• 时，会导致数据的重复去正火，但不会提供足够的读取性能优势大于重复的问题。


• 重新presenting的一对许多的关系


• 重新present的多到许多的关系。


• 相关数据的变化频繁的

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

一个规范化的数据模型的例子：

Example of a normalized data model:

{
  "Id": 1001,
  "Type": "Company",
  "Industry": "Software"
}

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

{
  "Id": 10012,
  "Type": "Employee",
  "Name": "Jane Doe",
  "CompanyId": 1001
}

混合方法

正火和去归一化之间进行选择不必是黑白的选择。我经常发现，一个成功的设计模式是一种混合的方法，在其中您可以选择正常化的部分设定一个对象的字段和去归了别人。

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.

混合方法的例子：

// 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"
  }, ]
}]

这篇关于单个或多个实体每收集在DocumentDB的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！