Firestore-Schema mit Claude Code entwerfen: Erst Queries, dann Collections

Firestore-Design beginnt nicht mit Collections

Ich bin Masa, Betreiber von claudecode-lab.com.

Mein erster Firestore-Entwurf sah wie ein relationales Datenmodell aus: users, posts, comments. Das wirkte sauber, bis echte Produktanforderungen kamen: veröffentlichte Posts nach Datum, Posts pro Autor, Drafts im Admin-Bereich und Tag-Seiten. Firestore lässt sich nicht später bequem mit Joins korrigieren.

Der bessere Ablauf: zuerst die Fragen der Anwendung auflisten, dann Dokumente und Indexe entwerfen.

Offizielle Referenzen:

• Firestore best practices
• Firestore index overview
• Firestore pricing

claude -p "
Entwirf Firestore für ein CMS.
Liste zuerst alle Queries nach Screen auf.
Gib where/orderBy/limit und notwendige Composite Indexes aus.
"

export interface PostDoc {
  id: string;
  slug: string;
  title: string;
  status: "draft" | "published" | "archived";
  lang: "ja" | "en" | "es" | "ko";
  authorId: string;
  authorName: string;
  tagSlugs: string[];
  tagNames: string[];
  publishedAt: FirebaseFirestore.Timestamp | null;
  updatedAt: FirebaseFirestore.Timestamp;
}

Kleine Anzeigefelder wie authorName bewusst zu duplizieren, kann zusätzliche Reads in Listen vermeiden. Indexe gehören in Git:

{
  "indexes": [
    {
      "collectionGroup": "posts",
      "queryScope": "COLLECTION",
      "fields": [
        { "fieldPath": "lang", "order": "ASCENDING" },
        { "fieldPath": "status", "order": "ASCENDING" },
        { "fieldPath": "publishedAt", "order": "DESCENDING" }
      ]
    }
  ]
}

Mein Ergebnis: Als ich diesen Query-first Ablauf auf Artikel, Kontakte und Logdaten angewendet habe, musste ich mehr als die Hälfte des ersten Schemas neu schreiben. Claude Code ist am stärksten, wenn es nicht sofort Code generiert, sondern zuerst Queries, Indexe und Risiken sichtbar macht.