El problema es que sobrenormalizas tus datos. Un pedido lo define un cliente, que vive en un lugar determinado en un momento dado, paga un precio determinado válido en el momento del pedido (que puede cambiar mucho durante la vida útil de la aplicación y que debe documentar de todos modos y varias otros parámetros que son todos válidos solo en un cierto punto de tiempo . Así que para documentar una orden (juego de palabras), debe conservar todos los datos para ese momento determinado. Déjame darte un ejemplo:
{ _id: "order123456789",
date: ISODate("2014-08-01T16:25:00.141Z"),
customer: ObjectId("53fb38f0040980c9960ee270"),
items:[ ObjectId("53fb3940040980c9960ee271"),
ObjectId("53fb3940040980c9960ee272"),
ObjectId("53fb3940040980c9960ee273")
],
Total:400
}
Ahora, siempre que no cambien el cliente ni los detalles de los artículos, puede reproducir a dónde se envió este pedido, cuáles eran los precios del pedido y similares. Pero ahora, ¿qué sucede si el cliente cambia su dirección? ¿O si cambia el precio de un artículo? Deberá realizar un seguimiento de esos cambios en sus respectivos documentos. Sería mucho más fácil y suficientemente eficiente para almacenar el pedido como:
{
_id: "order987654321",
date: ISODate("2014-08-01T16:25:00.141Z"),
customer: {
userID: ObjectId("53fb3940040980c9960ee283"),
recipientName: "Foo Bar"
address: {
street: "742 Evergreen Terrace",
city: "Springfield",
state: null
}
},
items: [
{count:1, productId:ObjectId("53fb3940040980c9960ee300"), price: 42.00 },
{count:3, productId:ObjectId("53fb3940040980c9960ee301"), price: 0.99},
{count:5, productId:ObjectId("53fb3940040980c9960ee302"), price: 199.00}
]
}
Con este modelo de datos y el uso de canalizaciones de agregación, tiene varias ventajas:
- No es necesario que realice un seguimiento independiente de los precios y las direcciones, los cambios de nombre o las compras de regalos de un cliente:ya está documentado.
- Con las canalizaciones de agregación, puede crear tendencias de precios sin necesidad de almacenar datos de precios de forma independiente. Simplemente almacena el actual precio de un artículo en un documento de pedido.
- Incluso las agregaciones complejas, como la elasticidad de precios, la facturación por estado/ciudad y similares, se pueden realizar utilizando agregaciones bastante simples.
En general, es seguro decir que en una base de datos orientada a documentos, cada propiedad o campo que está sujeto a cambios en el futuro y este cambio crearía un significado semántico diferente debe almacenarse dentro del documento. Todo lo que está sujeto a cambios en el futuro pero que no afecta el significado semántico (la contraseña de los usuarios en el ejemplo) puede vincularse a través de un GUID.
