Wenn du jemals auf deine Firestore-Konsole gestarrt hast und dich gefragt hast 'wo habe ich diese Daten hingelegt?' oder 'warum funktioniert diese Query nicht?', bist du nicht allein. Firestore ist mächtig, aber seine NoSQL-Natur bringt die meisten Entwickler ins Straucheln — besonders jene, die von SQL-Datenbanken kommen. Lass uns aufschlüsseln, warum es verwirrend ist und was du dagegen tun kannst.

Warum sich Firestore so anders anfühlt

Wenn du MySQL, PostgreSQL oder eine SQL-Datenbank genutzt hast, hast du dein Gehirn trainiert, in Tabellen, Zeilen und Joins zu denken. Firestore wirft das alles über den Haufen. Es gibt keine Tabellen — nur Sammlungen. Keine Zeilen — nur Dokumente. Keine Joins — nur denormalisierte Daten. Und keine Schema-Erzwingung — Dokumente in derselben Sammlung können völlig unterschiedliche Felder haben.

Die mentale Modellverschiebung:

SQL

Tabellen mit festen Spalten → Zeilen folgen einem strikten Schema → JOINs kombinieren verwandte Daten → Normalisierung vermeidet Duplikation

Firestore

Sammlungen mit flexiblen Dokumenten → Jedes Dokument kann unterschiedlich sein → Keine JOINs — denormalisiere stattdessen → Duplikation ist erwartet und gefördert

5 Fehler, die jeder Firestore-Anfänger macht

1. Alles zu normalisieren versuchen

In SQL normalisierst du, um Datenduplikation zu vermeiden. In Firestore zwingt dich das zu mehrfachen Lesevorgängen, um eine einzige Ansicht zusammenzustellen. Speichere stattdessen die Daten dort, wo du sie liest — auch wenn es bedeutet, den Anzeigenamen eines Benutzers in jedem Kommentar zu duplizieren, den er schreibt.

2. Arrays für Beziehungen verwenden

Ein Array von Benutzer-IDs in einem Dokument zu speichern erscheint logisch, aber Firestore-Arrays haben schwere Einschränkungen: Du kannst einzelne Elemente nicht effizient abfragen, und sie skalieren nicht über einige tausend Elemente hinaus. Nutze stattdessen Untersammlungen oder eine separate Sammlung mit Referenzen.

3. Alles in ein Dokument packen

Firestore berechnet pro Dokumentlesevorgang, daher ist es verlockend, alles in ein großes Dokument zu stopfen. Aber Dokumente haben ein 1-MB-Limit, und ein 500-KB-Dokument zu lesen, wenn du nur 2 Felder brauchst, verschwendet Bandbreite und erhöht Kosten. Teile in fokussierte, kleinere Dokumente auf.

4. Query-Einschränkungen im Voraus ignorieren

Firestore kann keine Ungleichheitsfilter auf mehrere Felder in einer einzigen Query anwenden, kann keine native Volltextsuche durchführen und benötigt Indizes für zusammengesetzte Queries. Entwirf dein Datenmodell von Tag eins an um deine Queries herum — nicht umgekehrt.

5. Die Struktur nicht dokumentieren

Ohne Schema wird deine Firestore-Datenbank zur Blackbox. Neue Teammitglieder raten Feldnamen, Tippfehler verursachen stille Bugs, und niemand weiß, ob ein Feld erforderlich oder optional ist. Das ist der häufigste und schädlichste Fehler.

Wie du Struktur in deine Firestore-Datenbank bringst

Die gute Nachricht: Du kannst Firestore Struktur hinzufügen, ohne seine Flexibilität aufzugeben. Hier sind drei praktische Schritte:

1Entwirf deine Queries zuerst

Bevor du Sammlungen erstellst, liste jeden Bildschirm in deiner App auf und welche Daten er braucht. Dieser Query-First-Ansatz stellt sicher, dass dein Datenmodell deiner Oberfläche dient — das Gegenteil des SQL-Denkens, wo du zuerst Tabellen entwirfst.

2Nutze konsistente Feldnamen und Typen

Entscheide früh über Konventionen: camelCase oder snake_case? Timestamps als Firestore Timestamps oder ISO-Strings? Erforderliche vs. optionale Felder? Schreibe diese Entscheidungen an einem Ort auf, den dein Team finden kann.

3Dokumentiere deine Sammlungen mit JSON Schema

JSON Schema ist ein offener Standard, der dir ermöglicht, die Struktur jeder Sammlung zu beschreiben: Feldnamen, Typen, welche erforderlich sind, welche Werte gültig sind. Es ist wie ein Bauplan für deine Datenbank — und es dient gleichzeitig als Dokumentation, die akkurat bleibt, wenn du sie in deinem Repository behältst.

Wie das in der Praxis aussieht

Hier ist ein einfaches JSON Schema, das eine Firestore-Benutzersammlung beschreibt. Beachte, wie jedes Feld einen Typ und eine Beschreibung hat — jeder in deinem Team kann das Datenmodell auf einen Blick verstehen:

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"]
  }
}

Diese Schema-Datei lebt in deinem Repository, wird in PRs überprüft und dient als Single Source of Truth für deine Benutzersammlung. Kein Raten mehr.

Verwandle Schemas in interaktive Dokumentation

Sobald du Schema-Dateien für deine Sammlungen hast, können Tools wie FireSchema sie als interaktive, durchsuchbare Dokumentation rendern — ähnlich wie Swagger UI für REST-APIs funktioniert, aber für NoSQL-Datenbanken entwickelt. Es ist kostenlos, Open Source und dauert etwa 5 Minuten zum Einrichten.

Nächste Schritte

Baue dein Firestore-Wissen weiter aus:

Warum Firestore verwirrend ist (und wie man es behebt)