c# - samples - query azure cosmos db

Entidades individuales o múltiples por colección en DocumentDB

Question

¿Debería haber una entidad por colección en el documento DB?

Considera que tengo una relación de clave externa en el siguiente diagrama:

Debo crear dos colecciones, una para el empleado y otra para la empresa. ¿O debería guardarlos en una sola colección?

Leí here que en el alcance de documentos de los activadores de procedimientos almacenados, etc., están dentro de una colección. Entonces, al dividir las diferentes entidades en una colección separada, pierdo la funcionalidad de la caja.

Entonces, ¿no sería mejor volcar ambas clases como una sola entidad como se muestra a continuación?

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

¿Cuál es la práctica estándar de implementar entidades relacionadas en DocumentDB?

Answer 1

En general, es bueno almacenar varios tipos de entidades por colección. Ya sea para almacenar tipos de entidades dentro de un solo documento o no se necesita un poco más de reflexión.

Como mencionó David, cómo modelar datos es un poco subjetivo.

Almacenamiento de múltiples tipos de entidades dentro de una colección

Primero ... hablemos sobre el almacenamiento de múltiples entidades en una colección. Las colecciones de DocumentDB no son tablas. Las colecciones no imponen el esquema; en otras palabras, puede almacenar diferentes tipos de documentos con diferentes esquemas en la misma colección. Puede rastrear diferentes tipos de entidades simplemente agregando un atributo de tipo a su documento.

Debe pensar en las colecciones como una unidad de partición y límite para la ejecución de consultas y transacciones. Por lo tanto, una gran ventaja para almacenar diferentes tipos de entidades dentro de la misma colección es que usted recibe soporte de transacciones de manera inmediata a través de sprocs.

Almacenamiento de múltiples tipos de entidades dentro de un documento

Si almacena varios tipos de entidades dentro de un solo documento, piense un poco más. Esto se refiere comúnmente a la des-normalización (captura de relaciones entre datos mediante la incorporación de datos en un solo documento) y normalización (captura de relaciones entre datos mediante la creación de enlaces débiles a otros documentos) sus datos.

Normalmente , la normalización proporciona un mejor rendimiento de lectura .

Es posible que la aplicación deba emitir menos consultas y actualizaciones para completar las operaciones comunes.

En general, use modelos de datos des-normalizados cuando:

• tener relaciones " contiene " entre entidades
• tener relaciones de uno a pocos entre entidades
• los datos des-normalizados cambian con poca frecuencia
• los datos des-normalizados no crecerán sin límite
• los datos des-normalizados son parte integral de los datos en el documento

Ejemplo de un modelo de datos des-normalizado:

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

Normalmente, la normalización proporciona un mejor rendimiento de escritura .

Proporciona más flexibilidad que la normalización.

Las aplicaciones del lado del cliente deben emitir consultas de seguimiento para resolver las referencias. En otras palabras, los modelos de datos normalizados pueden requerir más viajes de ida y vuelta al servidor.

En general, utilice modelos de datos normalizados:

• cuando la des-normalización resultaría en una duplicación de datos pero no proporcionaría suficientes ventajas de rendimiento de lectura para superar las implicaciones de la duplicación.
• representando relaciones de uno a muchos
• representan relaciones de muchos a muchos .
• los datos relacionados cambian frecuentemente

Ejemplo de un modelo de datos normalizado:

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

Enfoques híbridos

Elegir entre normalizar y des-normalizar no tiene que ser una opción en blanco y negro. A menudo he encontrado que un patrón de diseño ganador es un enfoque híbrido, en el que puede elegir normalizar un conjunto parcial de los campos de un objeto y des-normalizar los demás.

En otras palabras, puede elegir des-normalizar las propiedades estables (o inmutables) de lectura frecuente para reducir la necesidad de consultas de seguimiento, mientras que normaliza los campos escritos con frecuencia / mutantes para reducir la necesidad de expandir las escrituras.

Ejemplo de un enfoque híbrido:

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

Answer 2

Su pregunta es un poco subjetiva, ya que está pidiendo un diseño de entidad, y para eso, no hay una única respuesta correcta.

Sin embargo: desde un punto de vista más objetivo : no hay nada que le impida tener varios tipos de entidades dentro de una colección (por ejemplo, tipo de documento de la Company y tipo de documento del Employee , en su caso).

Necesitará incluir algún tipo de sugerencia para usted (tal vez una propiedad de type ) para ayudar a diferenciar los dos al ejecutar sus consultas. Pero, al tener ambos tipos dentro de la misma colección, ahora tiene un ámbito de colección para trabajar dentro. Con respecto a una propiedad de type : Como DocumentDB indexa todas las propiedades de manera predeterminada, una propiedad de type sería fácil de integrar en sus consultas.

EDITAR Se eliminó parte de 3 colecciones por unidad de capacidad, ya que esa disposición se eliminó cuando DocumentDB pasó de Vista previa a Producción.