Best Practices für Datenbankdesign

Aus den Normalisierungsprinzipien und praktischer Erfahrung haben sich eine Reihe von bewährten Praktiken etabliert.

Namenskonventionen

• Tabellennamen: Plural (kunden, produkte, bestellungen) – in der englischsprachigen Praxis oft singular, im Deutschen etabliert sich zunehmend der Plural.
• Spaltennamen: Singular, aussagekräftig, snake_case (vorname, bestelldatum, kunden_id).
• Primärschlüssel: Einheitlich id oder tabellenname_id.
• Fremdschlüssel: referenzierte_tabelle_id (z. B. kunden_id, produkt_id).

Datentypen wählen

Wählen Sie den kleinstmöglichen Datentyp, der Ihre Daten abdeckt:

• INT für ganze Zahlen, BIGINT für sehr große Zahlen.
• DECIMAL(10,2) für Geldbeträge (niemals FLOAT für Währungen).
• VARCHAR(n) für variable Texte mit sinnvoller Maximallänge.
• TEXT nur für lange Texte (Blogbeiträge, Kommentare).
• DATE für Datum, DATETIME für Datum mit Uhrzeit.
• BOOLEAN oder TINYINT(1) für Ja/Nein-Felder.

Constraints für Datenintegrität

Nutzen Sie Constraints, um die Datenqualität auf Datenbankebene sicherzustellen:

-- NOT NULL: Pflichtfeld
email VARCHAR(255) NOT NULL

-- UNIQUE: Eindeutigkeit erzwingen
email VARCHAR(255) UNIQUE

-- DEFAULT: Standardwert
status VARCHAR(50) DEFAULT 'offen'

-- CHECK: Wertebereich prüfen (MySQL 8.0+)
CHECK (preis >= 0)

-- FOREIGN KEY: Referenzielle Integrität
FOREIGN KEY (kunden_id) REFERENCES kunden(id) ON DELETE RESTRICT

-- NOT NULL: Pflichtfeld
email VARCHAR(255) NOT NULL

-- UNIQUE: Eindeutigkeit erzwingen
email VARCHAR(255) UNIQUE

-- DEFAULT: Standardwert
status VARCHAR(50) DEFAULT 'offen'

-- CHECK: Wertebereich prüfen (MySQL 8.0+)
CHECK (preis >= 0)

-- FOREIGN KEY: Referenzielle Integrität
FOREIGN KEY (kunden_id) REFERENCES kunden(id) ON DELETE RESTRICT

Vermeidung von Anti-Patterns

• Keine NULL-Werte in Fremdschlüsseln: Ein Fremdschlüssel sollte entweder auf einen existierenden Datensatz verweisen oder – wenn die Beziehung optional ist – NULL erlaubt sein. Überlegen Sie genau, was der Geschäftsfall erfordert.
• Keine EAV-Modelle (Entity-Attribute-Value) ohne Not: EAV-Modelle sind extrem flexibel, aber schwer abzufragen und zu warten. Verwenden Sie sie nur, wenn Sie wirklich dynamische Attribute benötigen.
• Keine komma-separierten Listen in einer Spalte: Ein Feld wie produkt_ids mit Werten wie 1,2,3 verletzt die 1NF und macht JOINs unmöglich.