Wann Datenbankregeln brechen:JSONB, Zähler, Cent

Wann Datenbankregeln brechen? Nur mit einem konkreten, dokumentierten Grund – und in der Praxis halten nur drei Gründe der Prüfung stand. Wirklich flexible Daten dürfen in JSONB statt in starren Tabellen liegen. Zähler, die live zu teuer zu berechnen wären, dürfen gespeichert werden. Und Geld wird immer als ganze Cent gespeichert. Alles andere bleibt strikt strukturiert.

Ich habe viele Worte darauf verwendet, Struktur zu predigen: jede Tatsache an genau einer Stelle, alles über Referenzen verbunden, keine Abkürzungen. Diese Regel – die 90-Prozent-plus-Disziplin aus „Datenbank-Normalisierung erklärt“ – hat eine Plattform ermöglicht, auf der Hunderte Tabellen ohne doppelte Daten synchron bleiben. In diesem Beitrag geht es um die andere Seite: die 10 %, in denen das Brechen der Regeln keine Abkürzung ist, sondern die richtige technische Entscheidung.

Wann Datenbankregeln brechen: die Regel vor den Ausnahmen

Zuerst der Rahmen. Auf meiner Plattform sind wahrscheinlich 95 % der Daten relational – saubere Tabellen, saubere Referenzen, saubere Struktur. Die Ausnahmen sind genau das: Ausnahmen, jede mit einer schriftlichen Begründung. Diese Reihenfolge ist wichtig, weil dir die KI ständig Regelbrüche anbieten wird, und „so ist es einfacher“ ist nie der Grund. Gefährlich ist nicht die Ausnahme, sondern die undokumentierte Ausnahme, die später niemand von einem Fehler unterscheiden kann.

Damit zu den drei Regelbrüchen, die ich bewusst einsetze.

Ausnahme 1: JSONB für wirklich flexible Daten

PostgreSQL – die Datenbank-Engine unter den meisten modernen SaaS-Produkten – hat eine Superkraft namens JSONB. Eine einzige Spalte kann ein ganzes Freiform-Dokument aufnehmen: beliebige Felder, beliebige Form, bei jeder Zeile anders. Es ist der Notausgang der strukturierten Welt.

Stell dir deine Datenbank als Aktenschrank mit beschrifteten Schubladen vor. JSONB ist die Schublade „Sonstiges“ – und eine Sonstiges-Schublade ist wirklich nützlich, solange dort nicht dein Reisepass liegt. Legitimer Inhalt: Dinge, deren Form du im Voraus nicht kennen kannst. Wenn deine Nutzer eigene Formulare bauen, hat jede Einsendung andere Felder – du kannst keine Schublade für Felder vorplanen, die es noch nicht gibt. Das Gleiche gilt für benutzerdefinierte Felder, Einstellungen pro Nutzer, Payloads aus den Systemen anderer Unternehmen, lose Metadaten und die Vorher/Nachher-Snapshots in Audit-Logs.

Die Ein-Satz-Regel, der ich folge:

Wenn du es mit anderen Daten verbinden, häufig abfragen oder Beziehungen erzwingen musst – mach es relational. Wenn es flexibel, nutzerdefiniert oder selten abgefragt ist – ist JSONB in Ordnung.

Das Zeichen, dass JSONB sicher ist: Die Daten gehören einer einzigen Zeile und werden nie unabhängig von ihr abgefragt. Genau dann können die Update-Probleme, die Struktur verhindern soll, gar nicht auftreten. Das Zeichen für einen Fehler: Du ertappst dich dabei, Fragen quer durch das JSONB stellen zu wollen – „alle Aufgaben mit dem Tag dringend“, „alle Bestellungen dieses Kunden“. Das sind Beziehungen, und Beziehungen gehören in Tabellen.

12 WochenDeine Konzernkarriere war nie der PlanBewirb dich beim Solopreneur Accelerator.Jetzt bewerben →

Ausnahme 2: Zähler, die du nicht live berechnen kannst

Strikte Struktur sagt: Speichere nie, was du berechnen kannst. Die Mitgliederzahl eines Kanals, die Durchschnittsbewertung eines Angebots, die Bewerbungszahl einer Stellenanzeige – all das lässt sich bei Bedarf aus den zugrunde liegenden Datensätzen zählen, und bei kleinem Umfang solltest du genau das tun.

Dann kommt die Skalierung. Eine Community, in der Kanäle 100.000 Beiträge enthalten, kann diese nicht bei jedem Seitenaufbau neu zählen. Ein Marktplatz mit 500.000 Angeboten kann die Durchschnittsbewertung nicht in jedem Suchergebnis neu berechnen. Ein Jobportal, bei dem Unternehmen 50.000 Bewerbungen erhalten, kann sie nicht bei jedem Profilaufruf live zählen. Ab diesem Punkt speicherst du die Zahl – eine vorberechnete Zählerspalte – und das Lesen kostet nichts.

Diese Disziplin verhindert, dass daraus Fäulnis wird: Jeder gespeicherte Zähler braucht einen Pflegemechanismus – einen Datenbank-Trigger oder eine Funktion, die ihn in dem Moment aktualisiert, in dem sich die zugrunde liegenden Daten ändern. Ein Zähler ohne diesen Mechanismus ist keine Optimierung, sondern eine Lüge, die darauf wartet, geglaubt zu werden. In meinem Schema hat jede einzelne Zählerspalte einen dokumentierten Mechanismus, der sie synchron hält, und die Design-Notizen halten fest, welcher es ist und wann er auslöst.

Eine Verfeinerung, die du übernehmen solltest: Aufrufzähler sind die Ausnahme innerhalb der Ausnahme. Sie werden asynchron aktualisiert – von der Seite nach dem Laden ausgelöst – statt per Trigger. So bremst das Zählen von Aufrufen nie eine Seite, Bots lassen sich herausfiltern und wiederholte Aufrufe entdoppeln. Exakte Zähler (Mitglieder, Stimmen, Bewerbungen) bekommen Trigger; Eitelkeitszähler werden lockerer behandelt.

Ausnahme 3: Geld ist immer in ganzen Cent

Das ist weniger ein „Regelbruch“ als die Weigerung, einen Standard zu übernehmen, der natürlich aussieht und still gefährlich ist. Wer 12,99 € als Dezimalzahl 12.99 speichert, lädt die Gleitkomma-Arithmetik des Computers in deine Finanzen ein – und Gleitkomma-Rechnung erzeugt winzige Rundungsfehler, die in einem Diagramm bloß hässlich sind, auf einer Rechnung aber inakzeptabel.

Die Lösung: Speichere jeden Geldbetrag als ganze Zahl von Cent. 12,99 € wird als 1299 gespeichert. Ganze Zahlen haben nie Rundungsfehler. Das gesamte Zahlungssystem von Stripe spricht diese Konvention – Beträge in der kleinsten Währungseinheit –, sodass deine Datenbank nativ zu deinem Zahlungsanbieter passt. Die Division durch 100 geschieht erst im letzten Moment, in der Anzeigeschicht, wo ein Fehler einen kosmetischen Bug kostet statt Geld.

In meinem Schema ist das absolut: Jeder Preis, jede Gebühr, jedes Trinkgeld und jede Summe sind ganze Cent. Keine Dezimalzahlen für Geld, nirgends, nie.

Die Meta-Regel: Ausnahmen werden aufgeschrieben

Beachte, was alle drei Ausnahmen gemeinsam haben. Jede hat einen engen Auslöser (unbekannte Form; gemessene Kosten der Live-Berechnung; die Natur von Geld). Jede hat einen Ausgleichsmechanismus (den JOIN-Test; Sync-Trigger; Umrechnung in der Anzeigeschicht). Und jede ist dokumentiert – meine Plattform führt eine Datei mit Design-Entscheidungen, die jede bewusste Abweichung auflistet, genau damit spätere Audits (durch Menschen oder KI) bewusste Technik von angesammelter Schlamperei unterscheiden können.

Das ist der eigentliche Unterschied zwischen einem professionellen Regelbruch und technischen Schulden: Das eine kommt mit schriftlicher Begründung, das andere mit einem Achselzucken.

Das BuchThe Solopreneur RevolutionLuis Gonçalves darüber, wie du neben dem Job mit KI ein Solopreneur-Business aufbaust.Zum Buch →

Häufig gestellte Fragen

Ist JSONB schlechte Praxis?

Nein – schlechte Praxis ist missbrauchtes JSONB. Für wirklich flexible, zeilengebundene Daten ist es das richtige Werkzeug und erspart sinnlose Komplexität. Der Fehlerfall ist, damit Datenbankdesign zu umgehen: Tags, Zuständige oder Beziehungen in einen JSON-Blob zu stopfen, weil das Entwerfen der richtigen Tabellen nach Arbeit aussah. Wende den JOIN-Test an, und JSONB bleibt ein Werkzeug statt einer Falle.

Woher weiß ich, wann ein Zähler gespeichert werden sollte?

Wenn Live-Zählen messbar schadet – eine Seite, die bei jedem Aufbau große Datenmengen neu zählt – und nicht früher. Berechne Zahlen zunächst bei Bedarf; speichere einen Zähler erst, wenn die Skalierung es erzwingt, und nie ohne den Trigger oder die Funktion, die ihn korrekt hält. Vorzeitige Zähler sind unverdiente Komplexität.

Warum nicht einfach eine Dezimalspalte für Geld?

Weil ganze Cent eine ganze Klasse finanzieller Bugs unmöglich statt unwahrscheinlich machen, und weil dein Zahlungsanbieter ohnehin in kleinsten Währungseinheiten denkt. Zwei Darstellungen von Geld – Cent bei Stripe, Dezimalzahlen in deiner Datenbank – bedeuten Umrechnungen überall, und jede Umrechnung ist eine Stelle, an der man sich bei der Rechnung eines Kunden irren kann.

Was passiert, wenn ich für alles JSONB nutze?

Du bekommst eine Datenbank, die keine Fragen beantworten kann. Keine Beziehungen, keine Integritätsprüfung, kein effizientes Filtern, mühsame Berichte – du hast einen Haufen Dokumente mit Zusatzschritten nachgebaut. Flexibilität, die du nicht brauchtest, erkauft mit der Abfragbarkeit, von der dein Business lebt. Behalte die Struktur für die 95 % und setze JSONB dort ein, wo die Form wirklich unbekannt ist.