Como não gostamos de unanimidades, após estudar um pouco chegamos a uma conclusão: o melhor modelo de dados é aquele que se encaixa em sua aplicação. Óbvio? Talvez. Mas o óbvio também tem que ser dito. Não há certo nem errado, mas sim aquilo que é adequado ao sistema que você está construindo. Aqui no blog já abordamos este assunto em outras oportunidades:
MongoDB é schemaless. Mas o que isso realmente significa?
Um pouco mais sobre Schemaless
Como exemplo, imagine qual das seguintes estruturas seria mais apropriada:
1 - Documentos e arrays aninhados:
2 - Os mesmos dados, mas em documentos/collections diferentes:
Não temos um "melhor' modelo, mas sim alguns prós e contras (cada aplicação terá seus próprios, mas listamos aqui alguns mais comuns):
Prós do modelo 1:
- Temos mais performance, maior velocidade no acesso;
- Em caso de termos vários servidores, podemos fazer uma distribuição local de documentos;
- Fazemos nosso acesso em apenas uma collection, sem necessidade de "chaves estrangeiras";
Contras do modelo 1:
- Os documentos ficam maiores e temos que respeitar o limite de 16MB por documento;
- Dificuldade para ordenar subdocumentos;
Prós do modelo 2:
- Provavelmente não haverá problema de tamanho;
- Mais facilidade para ordenação;
- Mais facilidade para manipulação;
Contras do modelo 2:
- Necessidade de "chave estrangeira";
- Manipulação de mais de uma collection;
- Complexidade adicional na hora de consultar os documentos;
- Queda significativa na performance devido à necessidade de múltiplos acessos.
Novamente, estes são alguns pontos de vista que temos até o momento. É papel do desenvolvedor e do administrador do banco pensar sobre qual o melhor modelo para gravação e leitura dos dados, sempre de acordo com a necessidade da aplicação.
Até o próximo post!
0 comentários:
Postar um comentário