[Conceito] - Modelagem Relacional com NoSQL

Conteúdo original nessa thread do Twitter

Ei dev,

Você já deve ter ouvido falar que NoSQL significa NOT ONLY SQL. E isso quer dizer que você pode, sim, também fazer relacionamentos com bancos NoSQL.

É um pouco diferente, poucos falam, mas é possível! E pode ser muito bom em alguns casos. 💕

cc @sseraphini

🧵

Vou abordar um conceito que deve ser facilmente aplicável em bancos NoSQL do tipo documento e chave-valor, ok? (MongoDB, DynamoDB, p.e.).

Os exemplos aqui usam JSON pq é fácil de entender e pode ser análogo a esses dois tipos de bancos NoSQL. Suave?

Frequentemente vi times com pouca experiência em NoSQL aplicarem o padrão "tipo por tabela" ("coleção" no caso do mongo). Ou seja, vai existir uma tabela pra usuário, outra pra produtos, etc.

E as relações um-para-muitos ficam aninhadas. Como nesse exemplo de usuários que podem ter mais de um endereço.

Pra alguns casos, isso pode ser ruim. Você fica "sem ângulo fácil" para acessar as coleções aninhadas. Você teria que acessar os itens raiz e extrair suas coleções aninhadas.

Ainda por cima, por ex., o DynamoDB comporta itens de até 400 KB – não serve para itens muito grandes.

Para fazer relacionamentos nesses tipos de bancos NoSQL, você precisar quebrar esse padrão de "uma tabela/colação por tipo". Suas tabs/cols passarão a comportar mais de um tipo de item/registro e que se referenciam. É super simples!

Algumas vantagens dessa abordagem relacional "intra-tabela/coleção":

• Evita duplicidade (imagina uma modelagem livro/autor).

• Você pode economizar I/O projetando apenas aquilo que lhe interessa (no mundo cloud isso é especialmente importante 💰).

Aqui estão referências sobre o assunto para DynamoDB:

Example of Modeling Relational Data in DynamoDB

E para MongoDB:

Model One-to-Many Relationships with Document References

É esse o Tweet! Obrigado por ter lido até aqui e pense melhor sobre seus relacionamentos, se é que me entende.

Comente suas dúvidas/contribuições aqui pra gente discutir!