Si vous avez déjà fixé votre console Firestore en vous demandant 'où ai-je mis ces données ?' ou 'pourquoi cette requête ne fonctionne-t-elle pas ?', vous n'êtes pas seul. Firestore est puissant, mais sa nature NoSQL déroute la plupart des développeurs — en particulier ceux venant de bases de données SQL. Décomposons exactement pourquoi c'est déroutant et ce que vous pouvez faire.

Pourquoi Firestore semble si différent

Si vous avez utilisé MySQL, PostgreSQL ou toute base de données SQL, vous avez entraîné votre cerveau à penser en tables, lignes et jointures. Firestore jette tout cela. Il n'y a pas de tables — juste des collections. Pas de lignes — juste des documents. Pas de jointures — juste des données dénormalisées. Et pas d'application de schéma — les documents dans la même collection peuvent avoir des champs complètement différents.

Le changement de modèle mental :

SQL

Tables avec colonnes fixes → Les lignes suivent un schéma strict → Les JOINs combinent les données liées → La normalisation évite la duplication

Firestore

Collections avec documents flexibles → Chaque document peut différer → Pas de JOINs — dénormalisez plutôt → La duplication est attendue et encouragée

5 erreurs que tout débutant Firestore commet

1. Essayer de tout normaliser

En SQL, vous normalisez pour éviter la duplication de données. Dans Firestore, cela vous force à faire plusieurs lectures pour assembler une seule vue. Au lieu de cela, stockez les données là où vous les lisez — même si cela signifie dupliquer le nom d'affichage d'un utilisateur dans chaque commentaire qu'il écrit.

2. Utiliser des tableaux pour les relations

Stocker un tableau d'ID utilisateur dans un document semble logique, mais les tableaux Firestore ont de sévères limitations : vous ne pouvez pas interroger efficacement les éléments individuels, et ils ne passent pas à l'échelle au-delà de quelques milliers d'éléments. Utilisez plutôt des sous-collections ou une collection séparée avec des références.

3. Tout mettre dans un seul document

Firestore facture par lecture de document, il est donc tentant de tout entasser dans un grand document. Mais les documents ont une limite de 1 Mo, et lire un document de 500 Ko alors que vous n'avez besoin que de 2 champs gaspille de la bande passante et augmente les coûts. Divisez en documents plus petits et ciblés.

4. Ignorer les limitations de requête dès le départ

Firestore ne peut pas faire de filtres d'inégalité sur plusieurs champs dans une seule requête, ne peut pas faire de recherche en texte intégral native, et nécessite des index pour les requêtes composées. Concevez votre modèle de données autour de vos requêtes dès le premier jour — pas l'inverse.

5. Ne pas documenter la structure

Sans schéma, votre base de données Firestore devient une boîte noire. Les nouveaux membres de l'équipe devinent les noms de champs, les fautes de frappe causent des bugs silencieux, et personne ne sait si un champ est obligatoire ou optionnel. C'est l'erreur la plus courante et la plus dommageable.

Comment apporter de la structure à votre base de données Firestore

La bonne nouvelle : vous pouvez ajouter de la structure à Firestore sans renoncer à sa flexibilité. Voici trois étapes pratiques :

1Concevez vos requêtes en premier

Avant de créer des collections, listez chaque écran de votre application et les données dont il a besoin. Cette approche axée sur les requêtes garantit que votre modèle de données sert votre interface — l'opposé de la pensée SQL où vous concevez les tables en premier.

2Utilisez des noms et types de champs cohérents

Décidez des conventions tôt : camelCase ou snake_case ? Timestamps comme Firestore Timestamps ou chaînes ISO ? Champs obligatoires vs optionnels ? Écrivez ces décisions quelque part où votre équipe peut les trouver.

3Documentez vos collections avec JSON Schema

JSON Schema est un standard ouvert qui vous permet de décrire la structure de chaque collection : noms de champs, types, lesquels sont obligatoires, quelles valeurs sont valides. C'est comme un plan pour votre base de données — et cela sert aussi de documentation qui reste exacte si vous la gardez dans votre dépôt.

Ce que cela donne en pratique

Voici un simple JSON Schema décrivant une collection users Firestore. Remarquez comment chaque champ a un type et une description — n'importe qui dans votre équipe peut comprendre le modèle de données d'un coup d'œil :

schemas/users.schema.jsonJSON

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "collection": "users",
  "description": "Registered app users",
  "schema": {
    "type": "object",
    "properties": {
      "displayName": {
        "type": "string",
        "description": "User's full name"
      },
      "email": {
        "type": "string",
        "format": "email",
        "description": "Login email address"
      },
      "role": {
        "type": "string",
        "enum": ["admin", "editor", "viewer"],
        "description": "Access control role"
      },
      "createdAt": {
        "type": "string",
        "format": "date-time",
        "description": "Account creation timestamp"
      }
    },
    "required": ["displayName", "email", "role", "createdAt"]
  }
}

Ce fichier de schéma vit dans votre dépôt, est examiné dans les PRs, et sert de source unique de vérité pour votre collection users. Plus de devinettes.

Transformez les schémas en documentation interactive

Une fois que vous avez des fichiers de schéma pour vos collections, des outils comme FireSchema peuvent les rendre sous forme de documentation interactive et navigable — similaire à la façon dont Swagger UI fonctionne pour les API REST, mais conçu pour les bases de données NoSQL. C'est gratuit, open-source, et prend environ 5 minutes à configurer.

Prochaines étapes

Continuez à développer vos connaissances Firestore :

Pourquoi Firestore est déroutant (et comment y remédier)