Firebase Database para Desenvolvedores SQL — Denormalização

ATENÇÃO! O FIREBASE TEM AGORA O CLOUD FIRESTORE QUE É UM SERVIÇO DE BASE DE DADOS MAIS SIMPLES DE ESTRUTURAR. SE VOCÊ ESTIVER A COMEÇAR UM PROJECTO, RECOMENDO QUE UTILIZE O FIRESTORE AO INVÉS DA REALTIME DATABASE.

De certeza que todos os desenvolvedores SQL conhecem o conceito “Normalização”, que consiste em evitar a duplicação desnecessária de dados. Mas no Firebase, utilizamos um conceito inverso: a denormalização.

Sim, é isso mesmo. Muitas vezes no Firebase temos de duplicar dados para simplificar e/ou reduzir queries.

Vamos olhar para o exemplo do artigo anterior. Lembre-se que para fazer a junção de dados de 2 nós diferentes, nós colocamos uma leitura de dentro de outra. Isto funciona com poucos dados. Mas se estivermos a executar esta query várias vezes, ou em um nó com uma grande quantidade de dados, você terá que eliminar a leitura que está dentro da outra e ler os dados apenas uma vez.

Mas actualmente, não é possível ler apenas uma vez, porque dentro do nó “estudantes” temos apenas o nome do usuário e não todos os dados. Mas e se ao invés de armazenar apenas o nome, armazenassemos todos os dados do usuário? Assim, poderiamos fazer apenas uma leitura e obteríamos todos os dados que precisamos.

Quando denormalizar?

Bom, é como eu digo desde a parte 2 desta série:

Temos de estructurar os nossos dados de acordo com a forma como eles serão visualizados

Então eu criei uma interface para servir de exemplo:

Repare que no topo de aplicação temos algumas abas, onde podemos ver os grupos de estudo de cada cidade. Para ter todos os grupos de Maputo, você provavelmente faria uma Query com orderByChild(“cidade”).equalTo(“maputo”).

Mas ao invés de fazer queries, você pode denormalizar. Isso significa criar um novo nó onde os grupos estão organizados de acordo com a cidade. Assim:

Desta forma, para obter todos os grupos sediados em Maputo é só fazer uma leitura directa:

DatabaseReference db1 = raiz.child("cidade_grupos/maputo");

E a vantagem disto é que agora podemos fazer outras queries, pois ainda temos os outros atributos dos grupos.

Se os dados estão duplicados, como posso garantir que quando altero um nó, os dados do outro nó sejam alterados também?

Essa é uma questão bastante comum, pois se alterarmos o nome de um grupo no nó “grupos”, essa alteração não irá se reflectir no nó “cidade_grupos”. Então, como vamos garantir a consistência de dados assim?

A resposta desta questão fica para o próximo artigo, onde vamos aprender a garantir a consistência dos nossos dados, utilizando lookups e multi-path updates (algo como “actualização em múltiplos nós”).

Caso tenha alguma dúvida ou sugestão, deixe abaixo nos comentários. Se você estiver tentando usar a Realtime Database e teve um problema, coloque ele no StackOverflow, explicando o que você fez e qual foi o erro que teve. De certeza que você obterá ajuda de mim ou de alguém da comunidade. 🙂