MongoDB: Grundkonzepte

MongoDB ist die mit Abstand bekannteste Dokument-Datenbank und der NoSQL-Vertreter, den du in der IHK-Prüfung am ehesten triffst. Sie wurde 2009 veröffentlicht, ist heute mit über zwei Jahrzehnten Reifezeit ein etabliertes Werkzeug für Web-Anwendungen, Mobile Backends und überall dort, wo flexible Datenstrukturen gefragt sind.

Diese Lektion legt das konzeptuelle Fundament: Was sind Dokumente, Collections, Datenbanken in MongoDB? Was ist BSON? Wie unterscheidet sich das von der SQL-Welt? Wir betrachten auch das wichtige Modellierungs-Dilemma Embedded vs. Referenced. CRUD-Befehle und Aggregationen folgen in den Lektionen 5 und 6.

1) Die MongoDB-Hierarchie

Wer aus der SQL-Welt kommt, findet die MongoDB-Begriffe schnell. Es gibt eine direkte Entsprechung zu fast jedem klassischen Konzept – nur eben mit anderem Namen und ohne erzwungenes Schema:

MongoDB-Begriffe und ihre SQL-Entsprechungen

Database

≈ SQL Database

Ein Container für mehrere Collections. Eine MongoDB-Instanz kann viele Datenbanken halten.

Collection

≈ SQL Tabelle

Eine Sammlung von Dokumenten – ohne erzwungenes Schema. Wird automatisch beim ersten Insert angelegt.

Document

≈ SQL Zeile

Ein BSON-Objekt mit Feldern und Werten. Jedes Dokument hat ein eindeutiges _id-Feld.

Field

≈ SQL Spalte

Ein Schlüssel-Wert-Paar im Dokument. Werte können verschachtelt sein (Sub-Dokumente, Arrays).

Wichtiger Unterschied: in SQL ist das Schema einer Tabelle statisch – alle Zeilen haben dieselben Spalten. In MongoDB ist es dynamisch – jedes Dokument kann andere Felder haben. Das ist Freiheit (keine ALTER TABLE-Schmerzen), aber auch Verantwortung (die Anwendung muss konsistente Strukturen schreiben).

2) Direkter Vergleich: SQL ↔ MongoDB

Wer aus der SQL-Welt kommt, findet eine direkte Übersetzungstabelle hilfreich. Hier die wichtigsten Konzepte und ihre MongoDB-Pendants:

SQL ↔ MongoDB Übersetzungstabelle

Konzept	SQL	MongoDB
Datenbank	CREATE DATABASE shop;	use shop
Tabelle/Collection	CREATE TABLE users (…);	db.createCollection("users")
Zeile/Document einfügen	INSERT INTO users VALUES (…);	db.users.insertOne({…})
Alle Zeilen lesen	SELECT * FROM users;	db.users.find()
Mit Filter	WHERE alter >= 18	{ alter: { $gte: 18 } }
Aktualisieren	UPDATE users SET … WHERE …	db.users.updateOne({…}, {$set: {…}})
Löschen	DELETE FROM users WHERE …	db.users.deleteOne({…})
Primärschlüssel	PRIMARY KEY (id)	_id (automatisch)
JOIN	JOIN bestellungen ON …	$lookup in Aggregation
Index	CREATE INDEX idx ON users(email);	db.users.createIndex({email: 1})

Achtung: die Übersetzungen sind grob – die Semantik ist nicht immer 1:1 dieselbe. SQL-JOINs sind z.B. das tägliche Brot in relationalen DBs. MongoDB's $lookup existiert seit Version 3.2, ist aber wesentlich teurer als ein JOIN in einer SQL-DB. In gut entworfenen MongoDB-Anwendungen vermeidet man Joins durch Datenmodellierung (siehe nächster Abschnitt).

3) BSON – das interne Datenformat

MongoDB speichert Daten nicht als reines JSON, sondern als BSON – „Binary JSON". Das ist konzeptionell wie JSON (Felder, Werte, Verschachtelung), aber:

Binär kodiert: schneller zu parsen und kompakter zu speichern als Text-JSON.
Reichere Datentypen: echte Datumswerte (ISODate), 64-bit Integer, Dezimalzahlen mit hoher Präzision (Decimal128 für Geld), Binärdaten, ObjectId, und mehr.
Längen-Präfixe: jedes BSON-Dokument trägt seine Länge im Header – das erlaubt schnelles Überspringen ohne komplettes Parsing.

Für dich als Entwickler*in ist das meist transparent: du arbeitest mit JSON-ähnlichen Strukturen im Client, und MongoDB übernimmt die Konvertierung. Wichtig zu wissen ist es trotzdem, weil manche Typen (insbesondere Decimal128 für Geldbeträge) nur in BSON existieren – in normalem JSON gibt es nur den ungenauen Number-Typ, was bei Cent-Beträgen zu Rundungsfehlern führen kann.

4) Die ObjectId – MongoDBs Primary Key

Jedes Dokument hat ein Feld _id, das automatisch eindeutig ist (entspricht dem Primary Key). Du kannst es selbst setzen oder MongoDB überlässt es, dann generiert die DB eine ObjectId – ein 12-Byte-Wert mit cleverer Struktur:

Anatomie einer ObjectId

Beispiel: 507f1f77bcf86cd799439011 – klick die Abschnitte:

507f1f77

bcf86cd7

439011

4 Byte Timestamp

5 Byte Random

1 Byte Reserved

3 Byte Counter

→ Klick einen Abschnitt der ObjectId um die Bedeutung zu sehen.

Praktischer Nebeneffekt: weil die Timestamp im Präfix steckt, sind ObjectIds näherungsweise sortiert nach Erstellungszeit. Du kannst ObjectId.getTimestamp() aufrufen und bekommst das Erstellungs-Datum des Dokuments zurück – ohne separate created_at-Spalte zu brauchen. Beachte aber: die Reihenfolge ist nicht exakt chronologisch (Counter resettet, mehrere Server-Prozesse), nur grob.

5) Modellierung: Embedded vs. Referenced

Die wichtigste Design-Entscheidung in MongoDB: wenn Daten zusammengehören (z.B. Nutzer und seine Adressen), wie modellierst du das? Es gibt zwei Ansätze. Embedded bedeutet: die Adressen sind als Sub-Dokumente direkt im Nutzer-Dokument enthalten. Referenced bedeutet: Adressen sind eine eigene Collection, und das Nutzer-Dokument enthält nur Referenzen (IDs) auf sie – ähnlich einem Foreign Key in SQL.

Embedded vs. Referenced – beide Ansätze

Faustregel: Embedded wenn „gehört zu" – die Daten machen ohne den Eltern-Kontext keinen Sinn, werden fast immer zusammen gelesen, und ändern sich selten unabhängig. Referenced wenn „verweist auf" – die Daten existieren eigenständig, werden auch ohne den Kontext gebraucht, oder werden separat häufig geändert. Die Entscheidung beeinflusst alle Operationen – darum vor dem Schreiben gut überlegen.

6) Schema-Validierung (wenn du sie brauchst)

„Schema-frei" heißt nicht, dass du nicht doch Regeln durchsetzen kannst. MongoDB unterstützt seit Version 3.2 JSON Schema Validation: du kannst pro Collection festlegen welche Felder welche Typen haben müssen. Ein praktischer Mittelweg zwischen totaler Freiheit und SQL-Strenge:

db.createCollection("users", {
  validator: {
    $jsonSchema: {
      bsonType: "object",
      required: ["name", "email"],
      properties: {
        name: { bsonType: "string" },
        email: { bsonType: "string", pattern: "@" },
        alter: { bsonType: "int", minimum: 18 }
      }
    }
  }
});

Ab dem Moment lehnt MongoDB Inserts ab, die nicht zum Schema passen. Das gibt dir SQL-ähnliche Garantien an den Stellen wo du sie brauchst – ohne die Flexibilität dort zu verlieren, wo du sie willst. In professionellen Projekten ist Validierung üblich; reine „wilde" Collections sind eher für Prototypen.

7) Transaktionen in MongoDB

Ein häufiges Missverständnis: „NoSQL hat keine Transaktionen". Das war früher wahr, gilt aber seit Version 4.0 (2018) nicht mehr für MongoDB. Es gibt Multi-Document-Transaktionen mit den klassischen Befehlen session.startTransaction(), session.commitTransaction(), session.abortTransaction(). Auch ACID-Garantien werden eingehalten.

Aber: Transaktionen über mehrere Dokumente sind in MongoDB teurer als in relationalen DBs. Das Design der Datenbank bestand ursprünglich darin, dass ein einzelnes Dokument als Einheit atomar geändert wird. Wenn deine Anwendung Multi-Dokument-Transaktionen viel braucht, ist das ein Zeichen, dass du eventuell zu „SQL-ähnlich" modellierst – oft hilft eine Embedded-Struktur, das gleiche Ziel mit einer einzelnen Dokumenten-Operation zu erreichen.

8) Indizes in MongoDB

Wie in SQL-Welt sind auch in MongoDB Indizes das wichtigste Performance-Werkzeug. Standardmäßig ist nur das _id-Feld indiziert. Für Felder, nach denen häufig gesucht wird, solltest du explizit Indizes anlegen:

// Einzelner Index aufsteigend
db.users.createIndex({ email: 1 });

// Composite Index (mehrere Felder)
db.users.createIndex({ stadt: 1, alter: -1 }); // 1 = asc, -1 = desc

// Unique Index
db.users.createIndex({ email: 1 }, { unique: true });

// Text-Index für Volltextsuche
db.products.createIndex({ description: "text" });

Wie in SQL gilt: nicht alles indizieren – Indizes verlangsamen Schreibvorgänge und kosten Speicher. Mit db.collection.find(…).explain() kannst du den Ausführungsplan ansehen, ähnlich dem EXPLAIN in SQL.

Zusammenfassung

MongoDB ist eine Dokument-Datenbank, die Daten als BSON-Dokumente in Collections speichert – flexibel im Schema, aber mit ähnlichen Konzepten wie SQL. Hierarchie: Database → Collection (≈ Tabelle) → Document (≈ Zeile) → Field (≈ Spalte). Jedes Dokument hat ein eindeutiges _id-Feld – meist eine 12-Byte ObjectId mit Timestamp, Random und Counter. BSON ist eine binäre JSON-Erweiterung mit reicheren Datentypen (ISODate, Decimal128). Wichtigste Modellierungs-Entscheidung: Embedded (Sub-Dokumente, wenn „gehört zu") vs. Referenced (Verweise, wenn „verweist auf"). Schema-Validierung kann optional aktiviert werden. Seit MongoDB 4.0 unterstützt die DB auch Multi-Document-Transaktionen mit ACID. Indizes funktionieren analog zu SQL und sind das wichtigste Performance-Werkzeug. Konkrete Operationen folgen in Lektion 5 (CRUD) und Lektion 6 (Aggregation).