Vous imbriquez plusieurs types de données sous une racine unique, ce que la plupart des développeurs de base de données Firebase Realtime recommandent. Certaines des plus importantes raisons sont les suivantes:
- Firebase lira toujours des nœuds entiers, donc vous ne pouvez pas lire les propriétés d'un utilisateur sans lire aussi toutes leurs conversations. Il y a beaucoup de scénarios où c'est gaspilleur, comme quand vous voulez seulement montrer une liste de noms d'utilisateur.
- Une fois que vous avez accordé à un utilisateur un accès en lecture à un noeud, il a accès à toutes les données sous ce noeud. Vous ne pouvez pas retirer cette permission à un niveau inférieur. Cela signifie que dans votre cas, toute personne capable de lire les informations de profil d'un utilisateur peut également lire toutes ses conversations. Ce n'est peut-être pas ce que vous voulez.
- Vous pouvez essayer de contourner cette dernière préoccupation en donnant à l'utilisateur une autorisation de lecture sur la propriété spécifique des utilisateurs, par exemple
/Users/$uid/name, etc. afin qu'ils puissent lire les noms, mais pas les conversations. Sur un nœud utilisateur individuel, cela fonctionnera en effet. Mais avec cette structure vous ne pouvez plus obtenir une liste de profils d'utilisateurs, puisque vous n'avez pas l'autorisation de lecture sur /Users.
La façon courante de modéliser ce que vous partagiez est de diviser les conversations et les profils utilisateurs en nœuds de haut niveau séparés, chaque calée sur l'UID de l'utilisateur:
Users
$uid
name: "Matias Celiz"
gender: "..."
Conversations
$uid
...
Si vous voulez séparé profil public informations et des informations de profil privé, ajouter un autre nœud de haut niveau pour diviser les deux:
Users
$uid
name: "Matias Celiz"
gender: "..."
Profiles
$uid
name: "Matias Celiz"
Conversations
$uid
...
