⚙️ MODELAGEM DE DADOS: O FIM DO JOIN

No RDBMS (Relacional), você modela as tabelas baseando-se no que será Guardado (Data-Driven). O aluno faz um MER focado primariamente na clareza (Normalização) (User, Pedido, Item) para evitar dados duplicados. Isso é lindo no Papel, mas mata o HDD. 🛡️🧩

Objetivo: Adotar a arquitetura Query-Driven Modeling (Modelagem Focada na Pergunta), compreendendo o motivo vital pelo qual o ecossistema Distribuído aboliu as amarras do RDBMS.

📗 PASSO 1: A Morte da Teoria dos Conjuntos Analíticos

⚠️ REGRA DE OURO E DE SANGUE: NÃO EXISTE JOIN NO CASSANDRA!

Se você tiver uma tabela de USUARIOS em um Nó no Japão, e a tabela de COMPRAS no Nó do Brasil, tentar realizar um SELECT ... INNER JOIN exigiria que milhões de Gigabytes subissem no cabo de fibra ótica cruzando o Oceano toda vez que alguém clicasse em "Ver meu Histórico". O Timeout quebraria a internet.

Portanto, o Cassandra abandonou a junção de servidor (JOIN). Para que as respostas sejam servidas em menos de 10 milissegundos, você precisou abolir a normalização e forçar a "Leitura Seqüencial".

📗 PASSO 2: Mudança de Paradigma (Query-Driven)

Para desenhar o seu banco a partir de agora, você precisa seguir este exato ritual:

1. Comece pelas Queries (Quais Perguntas a UI do seu App fará ao usuário?).
2. Desenhe uma Tabela Específica para Cada Pergunta.

💡 Dica de Performance: No Cassandra, duplicar dados não é pecado, é estratégia primária. Se seu App tem duas abas na interface ("Buscar por Usuário" e "Buscar por E-mail"), você não vai usar subconsultas secundárias ou Joins reversos. Você terá obrigatoriamente duas tabelas gigantes: users_by_id e users_by_email.

📗 PASSO 3: O Custo de Escrita vs. Custo de Leitura

No mundo anterior (SQL Clássico) aprendemos: "Evite gravar o mesmo dado duas vezes senão o HD acaba e a anomalia acontece."

No ecossistema de dados distribuído de altíssima escala (Cassandra/ScyllaDB), a verdade é matemática: Escrita é Barata, Leitura Cruzada é Extremamente Cara. O Cassandra foi projetado com otimizações nativas poderosas para escrever simultaneamente em 3, 5 ou 10 tabelas em microssegundos (utilizando o CommitLog em memória nativa), mas ele detesta ter que procurar peças que faltam usando a CPU dele (o Read dele é pior sem os metadados ideais).

Então, sempre crie e use comandos síncronos da sua Linguagem (Seu backend Node, Spring Boot, etc.) e mande ele inserir o mesmo evento de Venda nas 3 tabelas específicas ao vivo na hora da compra (Desnormalização Forte). 🚀🛡️