Notas do segundo encontro (15/04/2026)

Livro: Designing Data-Intensive Applications
Capítulo discutido: Capítulo 2 - Data models and Query Languages
Data da reunião: 15 de abril de 2026

Aviso: Este resumo foi gerado por IA usando como entrada o áudio transcrito da reunião.

Me ajude a gerar um relatório desta reunião de estudos que teve como foco
discussão do capitulo 2 (Data models and Query Languages) do
livro Designing Data Intensive Applications.

A transcrição está no arquivo "transcript.txt" no diretório atual.

Você deve criar um documento com os seguintes pontos:

1. Resumo (cerca de 300 palavras)
2. Principais tópicos debatidos (até 10)
3. Principais questões levantadas (ex. "Como gerenciar rollback em sistemas
com muitos usuários?")
4. Exemplos utilizados para ilustrar os conceitos abordados (tanto exemplo
presentes no livro quanto exemplos tragos do dia a dia profissional
dos participantes)

1. Resumo

A reunião discutiu como os modelos de dados são organizados em camadas e como cada camada abstrai a complexidade da camada inferior. O grupo começou pela ideia de modelar o problema no domínio (ex.: sistema de estudantes), depois converter para estruturas manipuláveis pelo computador (JSON, CSV, structs), em seguida escolher o modelo e mecanismo de persistência, e por fim considerar os níveis mais baixos de armazenamento e execução. Foi reforçada a importância de manter independência entre camadas e evitar dependências circulares.

Na sequência, o debate central foi a escolha entre bancos relacionais, documentais (NoSQL) e, mais adiante, grafos. Um ponto recorrente foi que a decisão não deve ser guiada apenas por “ter relacionamento ou não”, mas principalmente por padrão de acesso aos dados. O grupo usou o contraste entre modelos orientados a objeto e tabelas relacionais para explicar o impedance mismatch e o risco de consultas N+1 quando a consulta é mal estruturada.

Também foi discutido que NoSQL não significa “sem SQL”, mas “Not Only SQL”, e que na prática muitos sistemas misturam abordagens (ex.: PostgreSQL com JSONB). Surgiram trade-offs claros: documentos favorecem localidade dos dados e leitura agregada de entidades; relacionais favorecem normalização, consistência e consultas declarativas otimizadas pelo motor do banco. Em cenários com muitos relacionamentos (especialmente N:N), o grupo observou que o modelo documental pode perder eficiência e clareza, exigindo agregações e junções mais manuais na aplicação.

No trecho final, a conversa avançou para grafos: nós, arestas, múltiplos tipos de relacionamento e linguagens declarativas específicas (como Cypher), com comparação ao custo de simular grafos em SQL puro. Como encaminhamento, foi sugerido montar um laboratório prático para comparar performance, ergonomia de consulta e aderência à regra de negócio entre modelos relacional, documental e grafo.

2. Principais tópicos debatidos

1. Modelagem em camadas: domínio -> representação -> armazenamento -> nível físico.
2. Independência entre camadas e risco de dependência circular.
3. Diferença entre modelagem orientada a objeto e modelagem relacional.
4. Problema N+1 e impacto de consultas mal desenhadas.
5. Relacional vs documental com foco em padrão de acesso aos dados.
6. Normalização vs duplicação e “fonte única da verdade”.
7. Localidade de dados (documentos) vs distribuição em múltiplas tabelas.
8. Evolução de esquema: flexibilidade no documento vs rigidez controlada no relacional.
9. Limites do modelo documental em relacionamentos complexos (especialmente N:N).
10. Modelagem e consulta em grafos (nós/arestas, traversal e linguagens declarativas como Cypher).

3. Principais questões levantadas

• Como decidir entre relacional, documental e grafo sem se limitar ao critério “tem relacionamento”?
• Quando a busca por normalização compensa mais do que ganho de leitura por localidade?
• Em que ponto um modelo documental perde eficiência por excesso de referências e junções na aplicação?
• Como evitar o problema N+1 ao mapear objetos para tabelas relacionais?
• Até onde vale manter esquema flexível antes de gerar inconsistência de dados?
• Qual a diferença prática entre representar relações complexas em SQL vs usar banco de grafos?
• Como modelar relações N:N de forma sustentável em sistemas que crescem rápido?
• Quais ganhos reais de desempenho e manutenção em adotar consultas declarativas específicas de grafo?

4. Exemplos utilizados para ilustrar os conceitos

Exemplos do livro citados na reunião

• Exemplo de pedido com múltiplos itens para mostrar mapeamento objeto-relacional e risco de N+1.
• Exemplo do perfil tipo LinkedIn/Bill Gates para comparar documento único vs múltiplas tabelas normalizadas.
• Exemplo de relações entre usuário, empregos, organizações e escolas para discutir many-to-many.
• Exemplo de modelagem em grafo (lugares/pessoa e relação “nasceu em” -> “está em”) e consulta por padrão de caminho.

Exemplos práticos trazidos pelos participantes

• Arquitetura em camadas (analogia com Game Engine Architecture).
• APIs diferentes por plataforma (Windows/Linux) como analogia de abstração por camadas.
• Uso de struct em C para explicar proximidade de dados em memória.
• Cenário de grande escala (milhões de usuários) e impacto da distribuição de dados em múltiplas máquinas.
• Relato de projeto com MongoDB e dificuldades com dados duplicados, referências e perda de otimização.
• Proposta de laboratório para comparar relacional/documento/grafo em performance e complexidade de implementação.