Quando criamos um banco MongoDB a primeira coisa que devemos focar é em pensar na carga de trabalho.
| Operação | Tipo de trabalho | Informação | Frequência | Ctricidade | Latência | Tamanho | Vida útil dos dados | Sergurança |
|---|---|---|---|---|---|---|---|---|
| Qual ação será executada na aplicação? | escrita ou leitura | Qual(is) campos serão impactados na execução da operação? | Quantas execuções p/ dia? | alta, média ou baixa | Qual o tempo médio para execução da operação? | Qual o tamanho dos dados persistidos após a escrita | tempo em que os dados serão úteis na coleção | LGPD etc |
1) O quê se usa junto, se guarda junto
Ou seja, se os dados são criados/ alterados em uma mesma tela e em um mesmo formulário eles devem permanecer juntos em uma única coleção
2) Quando referenciar ou embarcar
I) Referenciar
- quando temos
n pra zilhão - quando hover muita escrita em ambas e há a necessidade de integridade nas relações
- quando uma parte dos dados é usada com frequência, mas a outra não
II) Embarcar
- para integridade das operações de leitura, ou seja, quando temos que ler todos os dados de uma só vez
- para integridade de operações de escrita "um pra um" ou "um pra muitos", desde que "muitos" não seja um número absurdo.
- dados que são excluídos ou arquivados juntos
- não sabe se referencia ou embarca, é melhor embarcar
O Padrão de Atributo é particularmente adequado quando:
- Temos documentos grandes com muitos campos semelhantes, mas há um subconjunto de campos que compartilham características comuns e queremos classificar ou consultar esse subconjunto de campos;
- Os campos que precisamos classificar são encontrados apenas em um pequeno subconjunto de documentos; ou
- Ambas as condições acima são atendidas nos documentos.
Referência:
Este pattern é adequado para aplicativos com junções repetidas e o aplicativo está tentando consultar os dados várias vezes.
A ideia por trás desse padrão é armazenar os dados acessados com frequência de um lado para muitos lados em um relacionamento um para muitos.
Ideal para campos que serão utilizados em uma interface com botões do tipo ver detalhes, clique aqui etc.
Referência:
Este pattern aproveita o suporte do MongoDB para que documentos com formatos diferentes existam na mesma coleção de banco de dados. Este aspecto polimórfico do MongoDB é muito poderoso. Ele permite que documentos que possuem campos diferentes ou até mesmo tipos de campos diferentes para o mesmo campo coexistam pacificamente lado a lado.
Referência:
Este pattern é indicado quando haverá o uso intensivo de leitura (significativamente mais leituras do que gravações para uma determinada 'entidade'). Quando temos dados que precisam ser computados repetidamente em nossa aplicação.
Referência
Este patterno aborda os problemas associados a um conjunto de trabalho que excede a RAM, resultando na remoção de informações da memória. Isso geralmente é causado por documentos grandes que contêm muitos dados que não são realmente usados pelo aplicativo.
Referência