CREATE TABLE, Datentypen, Constraints

Mit CREATE TABLE beginnt jede Datenbank: Du sagst dem DBMS, welche Tabellen es geben soll, welche Spalten sie haben, welche Datentypen, welche Regeln. CREATE TABLE gehört zur DDL (Data Definition Language) und definiert das Schema – also die Struktur, in die später Daten eingefügt werden.

Diese Lektion zeigt dir den kompletten Anatomie-Bauplan einer Tabelle: die Datentypen für jede Spalte, die Constraints für Datenintegrität, und die Best Practices, die in der IHK-Prüfung erwartet werden. Am Ende baust du selbst eine Tabelle im interaktiven Builder.

1) Die Grundform von CREATE TABLE

Die einfachste mögliche CREATE-TABLE-Anweisung sieht so aus:

CREATE TABLE kunde (
  id    INT,
  name  VARCHAR(100)
);

Drei Teile sind erkennbar: das Schlüsselwort CREATE TABLE, der Tabellenname (kunde), und in Klammern eine durch Kommas getrennte Spaltenliste. Jede Spalte hat einen Namen und einen Datentyp. Mehr braucht es nicht – aber so eine Tabelle ist auch ziemlich nutzlos. Sie hat keinen Schlüssel, keine Pflichtfelder, keine Größenbeschränkungen. In der Praxis kommen die Constraints dazu, die wir gleich besprechen.

2) Datentypen wählen – nach Kategorie

Der wichtigste Skill: für jede Spalte den passenden Datentyp finden. Falsche Wahl kostet Speicher, Performance oder Integrität (DECIMAL für Geld ist Pflicht – FLOAT führt zu Rundungsfehlern, die Buchhaltungen ruinieren können). Hier die wichtigsten Datentypen, gruppiert nach Verwendungszweck:

3) Constraints – Regeln in die Datenbank schreiben

Eine Tabelle ohne Constraints ist wie ein Formular ohne Pflichtfelder: Du kannst alles eintragen, auch Unsinn. Constraints sind die Wächter, die unsinnige Daten erst gar nicht in die Tabelle lassen. Sie werden direkt im CREATE-TABLE-Statement deklariert und vom DBMS automatisch durchgesetzt – jede einzelne Zeile bei jedem INSERT und UPDATE.

id INT PRIMARY KEY

name VARCHAR(100) NOT NULL

email VARCHAR(120) UNIQUE

status VARCHAR(20) DEFAULT 'offen'

preis DECIMAL(8,2) CHECK (preis > 0)

FOREIGN KEY (k_id) REFERENCES kunde(id)

id INT AUTO_INCREMENT PRIMARY KEY

PRIMARY KEY (stud_id, kurs_id)

4) Interaktiver Tabellen-Builder

Baue dir selbst eine Tabelle. Spalten hinzufügen, Datentyp wählen, Constraints ankreuzen – das SQL-Statement wird live darunter generiert. Probier verschiedene Kombinationen:

5) ALTER TABLE – nachträglich ändern

Eine Tabelle bleibt selten unverändert. Neue Spalten kommen dazu, Datentypen müssen angepasst werden, Constraints werden verschärft. ALTER TABLE ist das Werkzeug dafür. Die wichtigsten Varianten:

-- Neue Spalte hinzufügen
ALTER TABLE kunde ADD COLUMN telefon VARCHAR(20);

-- Spalte löschen
ALTER TABLE kunde DROP COLUMN telefon;

-- Datentyp ändern
ALTER TABLE kunde MODIFY COLUMN name VARCHAR(150);

-- Spalte umbenennen
ALTER TABLE kunde RENAME COLUMN name TO firmenname;

-- Constraint nachträglich hinzufügen
ALTER TABLE kunde ADD CONSTRAINT chk_email
  CHECK (email LIKE '%@%');

Achtung: ALTER TABLE auf großen produktiven Tabellen kann lange dauern und Locks erzeugen. In ernsthaften Umgebungen plant man solche Migrationen sorgfältig, oft mit Tools wie Flyway oder Liquibase, die Schema-Änderungen versioniert anwenden.

6) DROP TABLE – das ist endgültig

Die mit Abstand gefährlichste DDL-Anweisung. Sie löscht eine Tabelle vollständig – Struktur und Daten:

DROP TABLE kunde;  -- ALLES weg, ohne Rückfrage

Es gibt kein Backup-System der Welt, das gleichwertig zu vermeintlich gelöschten Daten ist. Wer DROP TABLE auf einem Produktivsystem ausführt, ohne zu wissen, was er tut, kann eine Firma in eine echte Krise stürzen. Daher: DROP nur in Skripten, die man dreifach reviewt hat. Und: immer aktuelles Backup verfügbar.

Eine sicherere Alternative ist TRUNCATE TABLE – das löscht nur die Daten, behält aber die Tabellenstruktur. Wird oft beim Zurücksetzen von Test-Daten verwendet:

TRUNCATE TABLE kunde;  -- Daten weg, Struktur bleibt

7) Praxis-Tipps für CREATE TABLE

Hier eine Checkliste der häufigsten Anfängerfehler – und wie du sie vermeidest:

• Immer Primary Key vergeben. Eine Tabelle ohne PK ist konzeptionell kaputt – keine eindeutige Identifizierung, keine JOINs, keine Performance. Wenn kein natürlicher Schlüssel da ist, technische id INT AUTO_INCREMENT PRIMARY KEY.
• NOT NULL nutzen, wo es sinnvoll ist. NULL macht Abfragen kompliziert (NULL ist nicht gleich NULL!). Nur Spalten, die wirklich optional sind, dürfen NULL sein.
• Datentypen großzügig, aber nicht verschwenderisch. Statt VARCHAR(255) für jeden Text-Feld: über die fachliche Länge nachdenken. Aber: ein Name kann durchaus 100 Zeichen lang sein.
• Datums-Spalten konsistent benennen. Konvention: erstellt_am, geaendert_am, geloescht_am – so sieht jeder auf einen Blick, was es ist.
• Foreign Keys nicht vergessen. Beziehungen zwischen Tabellen ohne FK ist Datenchaos vorprogrammiert.
• Spalten- und Tabellennamen nicht reservierte Wörter. order, group, user sind SQL-Schlüsselwörter und kollidieren. Nimm bestellung, gruppe, benutzer.

Zusammenfassung

CREATE TABLE definiert die Struktur einer Tabelle: Tabellenname plus eine Liste von Spalten mit ihren Datentypen und Constraints. Die wichtigsten Datentypen: INT/BIGINT (ganze Zahlen), DECIMAL(p,s) (für Geld, niemals FLOAT!), VARCHAR(n) (Text variabel) vs. CHAR(n) (Text fest), DATE/DATETIME/TIMESTAMP (Zeit), BOOLEAN (true/false), ENUM (Auswahl aus Liste). Die wichtigsten Constraints: PRIMARY KEY (eindeutiger Identifikator), NOT NULL (Pflichtfeld), UNIQUE (einmalig), DEFAULT (Standardwert), CHECK (Bedingung), FOREIGN KEY (Verweis auf andere Tabelle). Constraints werden vom DBMS automatisch erzwungen – das ist sicherer als Anwendungs-Validierung. ALTER TABLE ändert die Struktur nachträglich (ADD/DROP/MODIFY COLUMN). DROP TABLE löscht die Tabelle komplett – endgültig und gefährlich. TRUNCATE ist eine sicherere Alternative, die nur die Daten leert. Praxis-Tipps: immer PK, NOT NULL wo möglich, Datentypen mit Bedacht wählen, keine reservierten Wörter als Namen.

Verwandte Lektionen: SQL-Grundstruktur · INSERT, UPDATE, DELETE · Primary & Foreign Key · und mehrWeitere relevante LektionenER-Modell zu SchemaReferenzielle Integrität1. NormalformSELECT GrundabfragenMySQL PraxisInput-ValidierungDatenbankbackup