Typische Fehler beim Erstellen und Ändern von Tabellen

Hey, zukünftige PostgreSQL-Gurus! Das heutige Thema dreht sich um eine der wertvollsten Skills beim Programmieren – Fehler vermeiden. Ganz ohne Fehler geht’s natürlich nicht, vor allem wenn du gerade erst mit SQL anfängst. Aber die typischen Fehler schnell zu checken – das ist absolut machbar. Das ist wie nachts durch ein Zimmer mit vielen Ecken zu laufen: ein paar Mal stößt du dich, aber dann weißt du, wo alles steht. Ich helfe dir, die „scharfen Ecken“ beim Erstellen und Ändern von Tabellen zu umgehen.

Fehler 1: Falsche Wahl des Datentyps

Mit Datentypen zu arbeiten ist wie den richtigen Schlüssel für ein Schloss zu finden. Der falsche „Schlüssel“ in Form eines Datentyps kann dazu führen, dass deine Tabelle nicht richtig funktioniert oder weniger effizient ist.

Beispiel für einen Fehler:

Du willst eine Spalte für Telefonnummern anlegen und nimmst aus Gewohnheit den Typ INTEGER. Klingt logisch, sind ja Zahlen. Das Problem: INTEGER passt nicht für Daten, die:

• Mit einer Null anfangen (0123456789 wird einfach zu 123456789).
• Zeichen wie „+“ oder Leerzeichen enthalten.

-- Falsch:
CREATE TABLE customers (
    id SERIAL PRIMARY KEY,
    phone_number INTEGER -- Ups
);

-- Richtig:
CREATE TABLE customers (
    id SERIAL PRIMARY KEY,
    phone_number VARCHAR(15) -- Passt für alle Nummernformate
);

Wie vermeiden?
Überleg dir genau, welche Art von Daten du speichern willst, bevor du einen Datentyp auswählst. Wenn du unsicher bist, schau in die offizielle PostgreSQL-Dokumentation zu Datentypen.

Fehler 2: Constraints wie NOT NULL, CHECK, UNIQUE ignorieren

Constraints helfen, die Datenintegrität zu sichern. Wenn du sie vergisst, herrscht Chaos in deiner Tabelle – zum Beispiel gibt’s dann leere Werte, wo keine sein sollten.

Beispiel für einen Fehler: Du legst eine Tabelle für Studenten an und vergisst, dass Name und Alter Pflichtfelder sind.

-- Falsch:
CREATE TABLE students (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100),
    age INTEGER
);

INSERT INTO students (name, age) VALUES (NULL, NULL); -- Ups, was ist das?!

Richtige Variante:

CREATE TABLE students (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100) NOT NULL, -- Name ist Pflicht
    age INTEGER CHECK (age > 0) -- Alter muss positiv sein
);

Wie vermeiden?
Setz immer Constraints für Pflichtfelder. Das ist wie ein „Schutzmechanismus“, der Problem-Daten verhindert.

Fehler 3: Probleme mit der Einzigartigkeit

Manchmal vergisst du, ein UNIQUE-Constraint auf eine Spalte zu setzen, die eigentlich nur eindeutige Werte haben soll. Das führt zu doppelten Daten.

Beispiel für einen Fehler: Du legst eine Tabelle für E-Mail-Adressen an, vergisst aber das UNIQUE.

-- Falsch:
CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    email VARCHAR(100)
);

INSERT INTO users (email) VALUES ('user@example.com');
INSERT INTO users (email) VALUES ('user@example.com'); -- Diese E-Mail gibt’s schon!

Richtige Variante:

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    email VARCHAR(100) UNIQUE -- Eindeutige E-Mails
);

Wie vermeiden?
Setz immer UNIQUE, wenn Werte eindeutig sein müssen. Wenn du flexibel sein willst, kannst du auch CONSTRAINT mit Namen nutzen, um das Constraint zu benennen:

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    email VARCHAR(100),
    CONSTRAINT unique_email UNIQUE (email)
);

Fehler 4: Fehler beim Ändern von Tabellen (ALTER TABLE)

ALTER TABLE kann tückisch sein, besonders wenn schon Daten in der Tabelle sind. Zum Beispiel kannst du die erlaubten Werte in einer Spalte vergessen, was zu Fehlern mit bestehenden Daten führt.

Beispiel für einen Fehler: Du willst ein NOT NULL-Constraint zu einer bestehenden Spalte hinzufügen, aber es gibt schon NULL-Werte.

-- Falsch:
ALTER TABLE students ALTER COLUMN name SET NOT NULL; -- Fehler!

Wenn es schon Zeilen mit NULL gibt, lässt PostgreSQL das Constraint nicht zu.

Was tun?

Check vorher, ob die Daten passen, bevor du Constraints hinzufügst. Zum Beispiel:

UPDATE students SET name = 'Unbekannt' WHERE name IS NULL;
ALTER TABLE students ALTER COLUMN name SET NOT NULL;

Fehler 5: Tabellen oder Daten löschen ohne zu prüfen

Tabellen mit DROP TABLE oder Daten mit DELETE zu löschen ist endgültig. Deshalb immer checken, was du da eigentlich löschst.

Beispiel für einen Fehler:

DROP TABLE courses; -- Ups, das war die falsche Tabelle!

Wie vermeiden?

Nutze \dt in psql, um zu sehen, welche Tabellen es gibt, und sei sicher, dass du die richtige löscht.

Oder nutze DROP TABLE IF EXISTS, um Fehler zu vermeiden, falls die Tabelle gar nicht existiert:

DROP TABLE IF EXISTS courses;

Fehler 6: Probleme mit temporären Tabellen

Temporäre Tabellen verschwinden am Ende der Session. Versuchst du, eine temporäre Tabelle zu nutzen, nachdem die Session vorbei ist, gibt’s einen Fehler.

Beispiel für einen Fehler:

CREATE TEMP TABLE temp_students (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100)
);

-- Session beendet, und jetzt...
SELECT * FROM temp_students; -- Fehler: Tabelle gibt’s nicht mehr!

Wie vermeiden?

Speichere temporäre Daten, die du zwischen Sessions brauchst, in normalen Tabellen oder dokumentiere, dass sie nur in einer Session genutzt werden.

Fehler 7: Constraints beim Testen vergessen

Beim Entwickeln übersieht man oft Constraints und denkt „ach, das machen wir später“. Aber meistens wird „später“ vergessen.

Beispiel für einen Fehler:

CREATE TABLE test_table (
    id SERIAL PRIMARY KEY,
    name VARCHAR(50)
);

-- Daten einfügen:
INSERT INTO test_table (name) VALUES ('Doppelter Name');
INSERT INTO test_table (name) VALUES ('Doppelter Name'); -- Jetzt gibt’s Ärger...

Wie vermeiden?

Erstell Tabellen immer gleich mit Constraints, auch beim Testen:

CREATE TABLE test_table (
    id SERIAL PRIMARY KEY,
    name VARCHAR(50) UNIQUE -- Spart Kopfschmerzen
);