NoSQL/MongoDB mit Claude Code: Schema, Indexe und Aggregation

Erst Access Patterns, dann Collections

NoSQL/MongoDB ist keine Datenbank, die Daten in feste Zeilen und Spalten presst. MongoDB speichert Daten als JSON-nahe Dokumente. Deshalb beginnt ein gutes Modell nicht mit einer Liste von Collections, sondern mit der Frage, wie die Anwendung Daten liest, schreibt, sortiert, filtert und auswertet.

Claude Code liefert deutlich bessere Ergebnisse, wenn du nicht nur “baue mir ein Order-Schema” schreibst. Gib stattdessen Screens, API-Antworten, Update-Häufigkeit, Datenwachstum, Reporting-Anforderungen und Berechtigungsgrenzen mit. Dann kann Claude Code sinnvoll über Embedding, References, Indexe, Aggregation Pipelines, Validation Schema, Seed-Daten und Rollout-Risiken nachdenken.

Typische Use Cases

Use Case	Häufige Lesezugriffe	Passendes MongoDB-Modell	Hauptgefahr
E-Commerce-Bestellungen	Bestellungen pro Nutzer, Detailseite, Monatsumsatz	gekaufte Artikelnamen und Preise in die Bestellung einbetten, productId behalten	historische Bestellungen durch Produktänderungen verfälschen
SaaS-Audit-Logs	Organisation, Nutzer, Zeitraum, Event-Typ	append-only Dokumente, Compound Indexe, eventuell TTL	langsame Scans auf großer Collection
CMS-Artikel	Lookup per slug, Listen nach Status und Kategorie	klare Felder für slug, status und Veröffentlichungsdatum	Entwürfe oder interne Notizen werden sichtbar
Support-Tickets	Kundenqueue, Agentenqueue, letzte Kommentare	begrenzte Kommentare einbetten, Anhänge auslagern	ungebremst wachsende Arrays

Für den größeren Architekturvergleich helfen auch Datenbankdesign mit Claude Code, API-Entwicklung, Prisma ORM und SQL-Optimierung.

Ein besserer Prompt für Claude Code

Du bist der MongoDB Design Reviewer für dieses Projekt.
Entwirf das Modell zuerst aus den Access Patterns.

Anforderungen:
- Nutzer sehen ihre Bestellungen absteigend nach Datum.
- Die Bestelldetailseite zeigt Produktname, Preis und Kategorie zum Kaufzeitpunkt.
- Preisänderungen im Produktkatalog dürfen alte Bestellungen nicht verändern.
- Admins brauchen Umsatz nach Monat, Status und Artikelkategorie.
- Transactions nur dort einsetzen, wo Teilerfolg fachlich falsch wäre.
- Bitte Validation Schema, Indexe, Seed-Daten, Aggregation, Explain-Prüfung und Rollout-Checklist liefern.

Die Antwort sollte ausdrücklich nennen, welche Felder eingebettet und welche referenziert werden. In Bestellungen sind gekaufter Name, Preis und Kategorie Fakten des Kaufzeitpunkts. Lagerbestand, aktuelle Beschreibung und Merchandising-Daten bleiben dagegen im Produktdokument und werden über productId referenziert.

Lauffähiges Minimalbeispiel

MongoDB lokal starten:

docker run --name mongo-claude-demo -p 27017:27017 -d mongo:8

Offiziellen Node.js Driver installieren:

npm init -y
npm install mongodb
npm install -D tsx typescript
mkdir -p src

src/mongodb-workflow.ts anlegen:

import { MongoClient, ObjectId } from "mongodb";

const client = new MongoClient(process.env.MONGODB_URI ?? "mongodb://localhost:27017");

async function main() {
  await client.connect();
  const db = client.db("claude_code_shop_de");
  await db.dropDatabase();

  await db.createCollection("orders", {
    validator: {
      $jsonSchema: {
        bsonType: "object",
        required: ["userId", "status", "items", "totalAmount", "createdAt", "updatedAt"],
        properties: {
          userId: { bsonType: "objectId" },
          status: { enum: ["pending", "paid", "shipped", "cancelled"] },
          totalAmount: { bsonType: ["int", "long", "double", "decimal"], minimum: 0 },
          createdAt: { bsonType: "date" },
          updatedAt: { bsonType: "date" },
          items: {
            bsonType: "array",
            minItems: 1,
            items: {
              bsonType: "object",
              required: ["productId", "name", "category", "price", "quantity"],
              properties: {
                productId: { bsonType: "objectId" },
                name: { bsonType: "string" },
                category: { bsonType: "string" },
                price: { bsonType: ["int", "long", "double", "decimal"], minimum: 0 },
                quantity: { bsonType: "int", minimum: 1 }
              }
            }
          }
        }
      }
    }
  });

  const products = db.collection("products");
  const orders = db.collection("orders");

  await Promise.all([
    orders.createIndex({ userId: 1, createdAt: -1 }, { name: "orders_by_user_recent" }),
    orders.createIndex({ status: 1, createdAt: -1 }, { name: "orders_by_status_recent" }),
    orders.createIndex({ "items.category": 1, createdAt: -1 }, { name: "orders_by_category_month" })
  ]);

  const inserted = await products.insertMany([
    { name: "Claude Code Workshop", category: "training", currentPrice: 48000 },
    { name: "MongoDB Review Template", category: "template", currentPrice: 9800 }
  ]);

  const userId = new ObjectId();
  const now = new Date("2026-06-01T09:00:00.000Z");

  await orders.insertOne({
    userId,
    status: "paid",
    items: [
      { productId: inserted.insertedIds[0], name: "Claude Code Workshop", category: "training", price: 48000, quantity: 1 },
      { productId: inserted.insertedIds[1], name: "MongoDB Review Template", category: "template", price: 9800, quantity: 2 }
    ],
    totalAmount: 67600,
    createdAt: now,
    updatedAt: now
  });

  const report = await orders.aggregate([
    { $match: { status: { $in: ["paid", "shipped"] } } },
    { $unwind: "$items" },
    {
      $group: {
        _id: {
          month: { $dateToString: { format: "%Y-%m", date: "$createdAt" } },
          category: "$items.category"
        },
        revenue: { $sum: { $multiply: ["$items.price", "$items.quantity"] } },
        quantity: { $sum: "$items.quantity" }
      }
    },
    { $sort: { "_id.month": 1, revenue: -1 } }
  ]).toArray();

  const explain = await orders.find({ userId }).sort({ createdAt: -1 }).limit(10).explain("executionStats");
  if (report.length !== 2) throw new Error("aggregation failed");
  if ((explain.executionStats?.totalDocsExamined ?? 0) > 1) throw new Error("index check failed");

  console.log(JSON.stringify({ report, examined: explain.executionStats.totalDocsExamined }, null, 2));
}

main()
  .catch((error) => {
    console.error(error);
    process.exitCode = 1;
  })
  .finally(async () => {
    await client.close();
  });

Ausführen:

npx tsx src/mongodb-workflow.ts

Das Beispiel enthält Validation Schema, Indexe, Seed-Daten, Aggregation Pipeline und eine kleine explain-Prüfung. Genau diesen Output solltest du Claude Code zur Review geben, statt nur den Code generieren zu lassen.

Embedding oder Reference?

Embedding passt, wenn Daten fast immer gemeinsam gelesen werden und einen Zustand zu einem bestimmten Zeitpunkt beschreiben. References passen, wenn Daten unabhängig aktualisiert werden, unbegrenzt wachsen oder als einzige Wahrheit existieren müssen. Bestellte Artikel werden als Snapshot eingebettet; der Produktkatalog bleibt referenziert. Audit-Logs und Benachrichtigungen gehören nicht endlos in ein Account-Dokument.

Indexe, Aggregation und Transactions

Indexe werden aus echten Queries abgeleitet. find({ userId }).sort({ createdAt: -1 }) braucht { userId: 1, createdAt: -1 }. Aggregations sollten früh mit $match einschränken, nur notwendige Arrays mit $unwind entfalten und danach gruppieren. Schwere Admin-Reports können als Cache oder voraggregierte Collection stabiler sein.

Transactions sind sinnvoll, wenn ein Teilerfolg fachlich falsch wäre, etwa beim gleichzeitigen Markieren einer Bestellung als bezahlt und Schreiben des Payment-Records. Notifications, Suchindex-Syncs und View-Counter können oft asynchron oder idempotent verarbeitet werden.

Offizielle Referenzen: Data Modeling, Indexes, Aggregation, Transactions und MongoDB Node.js Driver.

Häufige Fehler

Der erste Fehler ist, relationale Normalisierung ungeprüft zu übernehmen. Wenn jedes Detail mehrere Lookups in der Anwendung braucht, nutzt du MongoDB gegen seine Stärken. Der zweite Fehler ist grenzenloses Embedding bei Kommentaren, Logs oder Benachrichtigungen. Der dritte ist fehlende DB-Validierung. Der vierte ist ein Index ohne explain("executionStats"). Der fünfte ist eine teure Aggregation auf jedem Seitenaufruf.

Vor dem Rollout sollten die wichtigsten Queries einem Index zugeordnet sein, Validation Schema und Seed/Test laufen, explain keine unerwarteten Scans zeigen, Transaction-Grenzen dokumentiert sein und Backup sowie Rollback geklärt sein.

ClaudeCodeLab unterstützt Teams mit Claude Code Training, CLAUDE.md Templates und Beratung für MongoDB- und API-Design. In der Praxis bringt diese Review-Schleife oft mehr als blind weitere Indexe anzulegen.