Entscheidung: den richtigen Datentyp wählen

Die Wahl des Datentyps gehört zu den Entscheidungen, deren spätere Korrektur am teuersten ist: Der falsche Typ erzeugt falsche Ergebnisse (z. B. Float für Geld), verschwendeten Platz und langsame Abfragen. Dieser Baum führt dich zum richtigen Typ für numerische, Text-, Datums-/Zeit-, Schlüssel- (PK), semistrukturierte (JSON) und Kategoriefelder (ENUM) und weist auf klassische Fallstricke wie Geld und Zeichensätze hin.

Welche Art von Daten speicherst du?

Der richtige Typ ergibt sich aus der Art der Daten. In welche Kategorie fällt das Feld: eine Zahl, Text, ein Datum/eine Uhrzeit, der Primärschlüssel der Tabelle, flexible/semistrukturierte Daten (JSON) oder eine begrenzte Menge von Kategorien?

• Numerischer Wert (Menge, Geld, Messwert, Zähler)
• Text (Name, Beschreibung, Code)
• Datum und/oder Uhrzeit
• Ich entwerfe einen Primärschlüssel (PK)
• Flexible/verschachtelte/variable Felder (semistrukturierte Daten)
• Eine begrenzte, bekannte Menge von Kategorien (Status, Typ, Priorität)

Ist die Zahl ganzzahlig oder dezimal — und ist es Geld?

Bei Zahlen ist die wichtigste Unterscheidung die Exaktheit. Ist der Wert ganzzahlig (Menge, ID, Zähler) oder dezimal? Wenn dezimal: Ist es GELD/ein Finanzbetrag? Binäre Gleitkommazahlen (FLOAT/DOUBLE) werden nie für Geld oder überall dort verwendet, wo Exaktheit gefordert ist, weil sie Rundungsfehler erzeugen.

• Ganzzahl (Menge, Zähler, id)
• Geld oder exakte Dezimalzahl (Preis, Saldo, Satz)

Empfehlung: Ganzzahl (SMALLINT / INT / BIGINT)

Wähle bei Ganzzahlen den kleinsten Typ, der den benötigten Bereich abdeckt. Ein unnötig großer Typ verschwendet Platz und Indexgröße; bei Feldern, die wachsen können, wie Zählern/PKs, ist ausreichende Breite aber unerlässlich, um Überläufe zu verhindern.

Empfehlung: NUMERIC / DECIMAL — NIEMALS FLOAT für Geld

Nutze für Geld und exakte Dezimalzahlen NUMERIC/DECIMAL mit Festkomma (exakt). FLOAT/DOUBLE sind binäre Gleitkommazahlen und können Werte wie 0.1 nicht exakt speichern; Addition/Multiplikation erzeugt Cent-Abweichungen, falsche Salden und Audit-Probleme.

Empfehlung: Text — VARCHAR vs. TEXT vs. CHAR

Für Text wird VARCHAR/TEXT bei variabler Länge und CHAR bei wirklich fester Länge verwendet. In modernen Engines ist der Speicherunterschied zwischen VARCHAR und TEXT meist vernachlässigbar; die eigentliche Entscheidung ist, ob ein semantisches Limit (Längenbeschränkung) gesetzt werden soll.

Empfehlung: Datum/Zeit — TIMESTAMP mit Zeitzone

Speicherst du einen Zeitpunkt (Ereigniszeit), wähle einen zeitzonenbewussten Typ. Speichern ohne Zeitzone führt über Regionen/Sommerzeitwechsel hinweg zu falschen Berechnungen und Vergleichen.

Empfehlung: Primärschlüssel — BIGINT vs. UUID

Für einen PK gibt es zwei Hauptoptionen: eine steigende Zahl (BIGINT Identity/Sequence) oder eine UUID. Ein numerischer PK ist klein und indexfreundlich, aber vorhersehbar und erfordert zentrale Erzeugung; eine UUID lässt sich verteilt erzeugen, ist aber größer und ihre zufällige Reihenfolge kann dem Index schaden.

Empfehlung: JSON / JSONB — maßvoll einsetzen

Der JSON-Typ ist stark für Felder mit flexiblem Schema, verschachtelte oder dünn besetzte Felder; die relationale Disziplin (Constraints, Indizes, Typsicherheit) kann aber verloren gehen. Regel: Feste und häufig abgefragte Felder in normale Spalten verlagern, nur den wirklich variablen Teil in JSON halten.

Empfehlung: ENUM vs. Lookup-Tabelle (Referenztabelle)

Für begrenzte Kategoriemengen gibt es zwei Optionen: den ENUM-Typ der Engine oder eine Lookup-Tabelle + Fremdschlüssel. ENUM ist kompakt und einfach, das Hinzufügen eines Werts erfordert aber eine Schemaänderung; eine Lookup-Tabelle ist flexibel und kann zusätzliche Attribute tragen (Beschreibung, Aktiv-Flag, Reihenfolge).