Firebase Firestore - approches de conception de données relationnelles

Question

Je suis totalement novice en matière de Firebase et j'essaie de comprendre la meilleure conception de modèle de base de données pour les données "relationnelles", à la fois 1-1 et 1-many.

Nous utilisons le Firestore (pas la base de données en temps réel).

Disons que nous avons Projects qui peut contenir plusieurs Users et un User peut être dans plusieurs Projects

L'interface utilisateur doit afficher une liste de Users dans un Project qui montre des choses comme email , firstname , lastname y department .

Quelle est la meilleure façon de conserver la relation ?

• Un tableau de User dans les Project document ?
• Une carte des identités dans le Project document ?

J'ai lu que les approches ci-dessus étaient recommandées, mais était-ce pour base de données en temps réel ? Firestore supporte les sous-collections, qui semblent plus appropriées...

• Une sous-collection de Users dans le document de projet ?
• Une cartographie de collection séparée Project id à User id ?
• A Reference type de données ? J'ai lu ici https://firebase.google.com/docs/firestore/manage-data/data-types à propos de Reference qui ressemble à ce que je veux, mais je ne trouve rien de plus à ce sujet !

S'il ne s'agit que d'une carte ou d'un tableau d'identifiants, comment récupérez-vous les autres données concernant l'utilisateur ? Cela devrait-il se faire dans l'interface utilisateur de l'application ?

S'il s'agit d'une sous-collection de documents d'Utilisateurs, y a-t-il un moyen de maintenir l'intégrité des données ? Si un utilisateur change de nom, l'interface utilisateur ou une fonction en nuage doit-elle mettre à jour chaque entrée de ce nom d'utilisateur dans les sous-collections ?

toute aide ou indication sera appréciée...

Answer 1

L'approche de la modélisation des relations many-to-many dans Firestore est à peu près la même que celle de la base de données en temps réel de Firebase, à laquelle j'ai répondu ici : Relation Many to Many dans Firebase . La seule différence est que vous pouvez stocker la liste de consultation dans une sous-collection de chaque projet/utilisateur.

La recherche de l'élément lié est également la même que précédemment, elle nécessite en effet de les charger individuellement depuis le client. Une telle jointure côté client est loin d'être aussi lente que vous ne le pensez, alors testez-la avant de penser qu'elle ne peut pas être assez rapide.

L'intégrité des données peut être assurée en effectuant écrites en lots ou en utilisant transactions . Soit ils réussissent complètement, soit ils échouent complètement.