Comment concevoir la structure de données Firestore optimale pour une recherche efficace de fournisseur-produit ?

Providers ( Collection )<br> Provider 1 ( Document )</p>
<div class="code" style="position:relative; padding:0px; margin:0px;"><pre class="brush:php;toolbar:false">  Name
  City
  Categories

Fournisseur 2

  Name
  City

Produits (Collection )
Produit 1 ( Document )

  Name
  Description
  Category
  Provider ID

Produit 2

  Name
  Description
  Category
  Provider ID

Justification :

• Duplication des données : Stockage des informations sur le fournisseur dans les documents produits (via l'ID du fournisseur) est une technique de dénormalisation efficace, conduisant à des temps de lecture plus rapides. L'accès aux deux collections est toujours possible lorsque cela est nécessaire.
• Cohérence des données : Bien que la dénormalisation élimine le besoin de lectures multi-documents, le maintien de la cohérence des données reste essentiel. Les mises à jour des informations du fournisseur doivent être reflétées dans tous les documents produits associés.
• Performances et coûts : La duplication des données du fournisseur peut augmenter l'utilisation du stockage, mais ce compromis est justifié par des requêtes plus rapides. Firestore facture les appels d'API et les écritures plus lourdement que les opérations de lecture.
• Sécurité : Il est crucial de créer une règle de sécurité appropriée pour protéger les informations du fournisseur tout en autorisant les requêtes liées au produit.

Alternative Structures :

• Stockage des références uniquement : Le fait de conserver uniquement les références des fournisseurs dans les documents produits simplifie l'écriture mais complique la lecture (nécessitant plusieurs appels d'API).
• Duplication complète du fournisseur : La copie de l'intégralité de l'objet fournisseur dans les documents du produit élimine les appels supplémentaires mais augmente la complexité d'écriture et le stockage. utilisation.

Choisir l'approche optimale :

La structure de données la plus appropriée dépend en fin de compte des besoins et des exigences spécifiques de l'application. Les facteurs à prendre en compte incluent la taille des données, la fréquence des mises à jour, les contraintes de performances de lecture et les implications en termes de coûts.

Discussions connexes :

• [Collections Firestore, cartes et Les tableaux expliqués](lien vers l'article connexe)

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!