Modelagem de dados no Firebase Firestore

Firebase é uma plataforma desenvolvida pelo Google com várias funcionalidades para a criação de aplicativos, como analíticas, autenticação, banco de dados e hospedagem.

Hoje vamos ver como modelar dados no Cloud Firestore, que é o banco de dados oferecido pelo Firebase.

A primeira coisa a se notar é que o Firestore é orientado a documentos. Diferente de bancos com SQL (Strutuced Query Language), que é baseado em tabelas e colunas, bancos de dados orientados a documentos são baseados em coleções de documentos.

• Coleções: podem ser entendidas como um array de documentos.
• Documentos: podem ser considerados um objeto JSON normal.

É importante lembrar que quando um documento é pesado, as consultas ao banco ficam lentas. Por isso, para manter as consultas eficientes, devemos seguir a regra:

“Coleções extensas, documentos leves.”

• Coleções: podem ser extensas (não há problemas em armazernar milhões de documentos)
• Documentos: devem ser leves (lentidão nas consultas quando maior que 1MB)

Além de armazernar dados em forma de objeto, documentos também podem ter subcoleções. Essas coleções ficam armazenadas no escopo do documento pai.

Chega de teoria e vamos logo ver um exemplo na prática:

Nesse exemplo, precisamos modelar o banco de dados de um aplicativo que tem muitos usuários. Cada usuário tem um nome e pode ter várias conquistas diferentes.

(Você pode criar seu próprio projeto Firebase e acompanhar a resolução. Entre com sua conta do Google, crie um novo projeto e depois crie seu banco de dados Cloud Firestore.)

Já que vamos ter vários usuários, começamos por criar uma coleção chamada “users”. Cada usuário vai ser um documento dentro dessa coleção.

Ao adicionar o primeiro documento, ou usuário, criamos um campo “name” que contém o nome do usuário.

(Use o gerador de id automático pra não ter que digitar um id você mesmo.)

Vamos obter algo assim:

Agora podemos adicionar um campo chamado “achievements”.

Esse campo será do tipo ‘map’ e armazenará as consquistas do usuário.

Agora já conseguimos armazenar os dados dos usários de uma forma bem simples.

Isso é muito bom! Mas lembre-se que um documento deve conter no máximo 1MB. Então, se quisermos adicionar milhares de conquistas, essa não é a melhor solução.

Para resolver esse problema, devemos em vez de armazenar as conquistas em um map, armazenar em uma subcoleção chamada “achievements”.

(Primeiro delete o campo “achievements” anterior)

E agora podemos adicionar cada conquista como um documento.

E agora podemos ter milhões de conquistas na mesma coleção, sem precisar se preocupar com espaço. 😁

Mas, ainda tem outra coisa que precisamos pensar ao modelar um banco de dados, que tipo de consultas vamos fazer.

Na última solução, nós podemos facilmente pegar um usuário e ver as conquistas que ele tem. Mas, e se quiséssemos pegar todos os usuários com um tipo de conquista específico? 😬

Infelizmente, não podemos fazer isso com essa modelagem, porque a coleção de conquistas pertence ao escopo de um único usuário. 😢

Mas, a boa notícia é que podemos remodelar nossos dados para tornar isso possível. 😃

Já que o problema é que a coleção de conquistas está no escopo de um usuário, por que não colocar essa coleção na raiz do nosso banco assim como a coleção “users”?

Exclua a antiga coleção de “achievements” e crie uma nova com as conquistas disponíveis ao lado da coleção de usuários.

Agora só falta referenciar cada conquista com seus respectivos ‘donos’. Como mais de um usuário pode ter a mesma conquista, vamos criar uma coleção chamada “users” dentro de cada conquista.

Nessa coleção, cada documento vai ter um “id” que aponta para o id do usuário pertencente.

Com essa alteração simples, podemos armazenar quantas conquistas quisermos, e ainda listar todos os usuários com um tipo de conquista. 😁

Nesse breve exemplo vimos como fazer relações:

• um pra um: um usuário pode ter uma conquista
• um pra vários: um usuário pode ter várias conquistas
• vários pra vários: um usuário pode ter várias conquistas e uma conquista pode ter vários usuários

Com isso, vimos o básico sobre modelagem de dados no Cloud Firestore. 😁😁😁