O problema é que você normaliza demais seus dados. Um pedido é definido por um cliente, que mora em um determinado local em um determinado momento, paga um determinado preço válido no momento do pedido (que pode mudar muito ao longo da vida útil do aplicativo e que você precisa documentar de qualquer maneira e vários outros parâmetros que são todos válidos apenas em um determinado momento . Então, para documentar um pedido (trocadilho intencional), você precisa persistir todos os dados para esse determinado ponto no tempo. Deixe-me lhe dar um exemplo:
{ _id: "order123456789",
date: ISODate("2014-08-01T16:25:00.141Z"),
customer: ObjectId("53fb38f0040980c9960ee270"),
items:[ ObjectId("53fb3940040980c9960ee271"),
ObjectId("53fb3940040980c9960ee272"),
ObjectId("53fb3940040980c9960ee273")
],
Total:400
}
Agora, desde que nem o cliente nem os detalhes dos itens mudem, você pode reproduzir para onde esse pedido foi enviado, quais eram os preços do pedido e similares. Mas agora o que acontece se o cliente mudar de endereço? Ou se o preço de um item mudar? Você precisaria acompanhar essas alterações em seus respectivos documentos. Seria muito mais fácil e suficientemente eficiente para armazenar o 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}
]
}
Com esse modelo de dados e o uso de pipelines de agregação, você tem várias vantagens:
- Você não precisa acompanhar preços e endereços de forma independente ou mudanças de nome ou compras de presentes de um cliente - isso já está documentado.
- Usando pipelines de agregação, você pode criar tendências de preços sem a necessidade de armazenar dados de preços de forma independente. Você simplesmente armazena o valor atual preço de um item em um documento de pedido.
- Mesmo agregações complexas, como elasticidade de preço, rotatividade por estado/cidade e similares, podem ser feitas usando agregações bem simples.
Em geral, é seguro dizer que em um banco de dados orientado a documentos, toda propriedade ou campo que está sujeito a alterações no futuro e essa alteração criaria um significado semântico diferente deve ser armazenado dentro do documento. Tudo o que está sujeito a alterações no futuro, mas não toca o significado semântico (a senha do usuário no exemplo) pode ser vinculado por meio de um GUID.
