Nem sempre, normalizar até o ponto de morte inflige acertos de desempenho, mas é verdade que eu pessoalmente não aplico a mesma normalização ao MongoDB que faço ao SQL.

Se você estiver ciente dos formulários normalizados ( http://en.wikipedia.org/wiki/Database_normalization ) Eu gosto de pensar que o MongoDB vai para 1NF e depois volta para desnormalizado novamente.

Ah sim temos. A atualização é uma dor se os dados forem duplicados incorretamente.

Deixe-me dar um exemplo:category e product seriam duas entidades separadas, não há como negar. Essas duas entidades são normalizadas (os dados repetidos de product foi lançado de category ). Outra maneira de pensar é:Todos os produtos existirão apenas em uma categoria?

Portanto, em entidades de nível superior, como você pode ver, as mesmas regras se aplicam relativamente com 1NF sendo facilmente aplicado ao MongoDB.

Na frente da duplicação, é claro que você não deseja armazenar cada produto separadamente em cada categoria (respondi não à pergunta acima), portanto, naturalmente, você deseja separar categorias e produtos.

Você normalmente teria um relacionamento muitos para muitos aqui com uma tabela normalizada no meio. É aqui que a desnormalização pode entrar. Você pode dizer que uma categoria terá uma lista de produtos exclusivos para essa categoria, assim você pode desnormalizar a tabela relacional muitos-para-muitos na linha da categoria como uma lista (ou vice-versa na linha de produtos). Isso não gerará duplicação, pois essa lista é exclusiva dessa categoria (mais do que provável). Obviamente, isso significa que a categoria ou os produtos abrigariam uma lista _id s da linha relacionada em vez do próprio objeto.

Há momentos em que a duplicação é necessária, principalmente para otimizar ou contornar por não ter JOINs; esta regra também se aplica ao SQL se você já fez um site grande o suficiente.

Cenários de uso típicos de duplicação são campos de agregação de estatísticas, como compartilhamentos e comentários de postagens do Facebook, e talvez até os 5 comentários mais recentes dessa postagem também sejam duplicados na linha de postagem.

Portanto, não se trata de ignorar o design do esquema, mas sim de ajustá-lo para as características do MongoDBs. Normalmente, se você fizer isso, descobrirá que, naturalmente, projeta um bom esquema.

Como referência adicional, você pode consultar aqui:http://docs.mongodb.org/ manual/núcleo/modelagem de dados