Typowe błędy przy tworzeniu i modyfikacji tabel

Cześć, przyszli guru PostgreSQL! Dzisiejszy temat to chyba jedna z najważniejszych umiejętności w programowaniu — unikanie błędów. Wszystkich oczywiście nie da się uniknąć, zwłaszcza jeśli dopiero zaczynasz przygodę z SQL. Ale ogarnąć typowe błędy — to już całkiem realne. To jak chodzenie po ciemku po pokoju z wieloma rogami: parę razy się uderzysz, ale potem już wiesz, gdzie co stoi. Ja pomogę Ci ominąć "ostre rogi" przy tworzeniu i modyfikacji tabel.

Błąd 1: Zły wybór typu danych

Praca z typami danych to jak dobieranie klucza do zamka. Zły "klucz" w postaci typu danych może sprawić, że tabela będzie działać niepoprawnie albo mniej wydajnie.

Przykład błędu:

Chcesz stworzyć kolumnę do przechowywania numerów telefonów i z przyzwyczajenia wybierasz typ INTEGER. Brzmi logicznie, bo numery to przecież liczby. Ale problem w tym, że INTEGER nie nadaje się do danych, które:

• Zaczynają się od zera (0123456789 stanie się po prostu 123456789).
• Zawierają znaki, takie jak "+" albo spacje.

-- Źle:
CREATE TABLE customers (
    id SERIAL PRIMARY KEY,
    phone_number INTEGER -- Oj oj
);

-- Dobrze:
CREATE TABLE customers (
    id SERIAL PRIMARY KEY,
    phone_number VARCHAR(15) -- Nadaje się do wszystkich formatów numerów
);

Jak tego uniknąć?
Zawsze analizuj dokładnie, jakie dane będziesz przechowywać, zanim wybierzesz typ danych. Jeśli masz wątpliwości, zajrzyj do oficjalnej dokumentacji PostgreSQL o typach danych.

Błąd 2: Ignorowanie ograniczeń NOT NULL, CHECK, UNIQUE

Ograniczenia pomagają utrzymać spójność danych. Jeśli o nich zapomnisz — w Twojej tabeli zacznie się chaos, np. pojawią się puste wartości tam, gdzie nie powinno ich być.

Przykład błędu: Tworzysz tabelę do przechowywania studentów i zapominasz, że imię i wiek studenta są obowiązkowe.

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

INSERT INTO students (name, age) VALUES (NULL, NULL); -- O nie, co to?!

Poprawna wersja:

CREATE TABLE students (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100) NOT NULL, -- Imię obowiązkowe
    age INTEGER CHECK (age > 0) -- Wiek musi być dodatni
);

Jak tego uniknąć?
Zawsze ustawiaj ograniczenia dla obowiązkowych pól. To taki "mechanizm ochronny", który nie pozwoli na wprowadzenie problematycznych danych.

Błąd 3: Problemy z unikalnością

Czasem możesz zapomnieć dodać ograniczenie unikalności UNIQUE do kolumny, która powinna mieć unikalne wartości. To prowadzi do duplikatów.

Przykład błędu: Tworzysz tabelę do przechowywania adresów email, ale zapominasz dodać UNIQUE.

-- Źle:
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'); -- Ten email już istnieje!

Poprawna wersja:

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    email VARCHAR(100) UNIQUE -- Unikalne emaile
);

Jak tego uniknąć?
Zawsze dodawaj UNIQUE, jeśli wartości mają być unikalne. Jeśli chcesz mieć większą kontrolę, możesz użyć CONSTRAINT z nazwą, żeby łatwiej zidentyfikować ograniczenie:

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

Błąd 4: Błąd przy zmianie tabel (ALTER TABLE)

Używanie ALTER TABLE może być podchwytliwe, szczególnie jeśli w tabeli są już dane. Na przykład możesz zapomnieć o dozwolonych wartościach w kolumnie, co spowoduje błędy przy pracy z istniejącymi danymi.

Przykład błędu: Chcesz dodać ograniczenie NOT NULL do już istniejącej kolumny, ale w tej kolumnie są wartości NULL.

-- Źle:
ALTER TABLE students ALTER COLUMN name SET NOT NULL; -- Błąd!

Jeśli w tabeli są już wiersze z NULL, PostgreSQL nie pozwoli Ci dodać ograniczenia.

Co zrobić?

Przed dodaniem ograniczeń upewnij się, że dane spełniają wymagania. Na przykład:

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

Błąd 5: Usuwanie tabel lub danych bez sprawdzenia

Usuwanie tabeli za pomocą DROP TABLE albo danych przez DELETE — to akcja nieodwracalna. Dlatego przed usunięciem zawsze sprawdź, co dokładnie usuwasz.

Przykład błędu:

DROP TABLE courses; -- Oj, to była nie ta tabela!

Jak tego uniknąć?

Użyj komendy \dt w psql, żeby zobaczyć, jakie tabele istnieją i upewnij się, że usuwasz właściwą.

Albo użyj DROP TABLE IF EXISTS, żeby uniknąć błędów przy próbie usunięcia nieistniejącej tabeli:

DROP TABLE IF EXISTS courses;

Błąd 6: Problemy z tabelami tymczasowymi

Tabele tymczasowe znikają na końcu sesji. Jeśli przez pomyłkę spróbujesz użyć tabeli tymczasowej, a sesja już się skończyła, dostaniesz błąd.

Przykład błędu:

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

-- Zakończyłeś sesję, a teraz...
SELECT * FROM temp_students; -- Błąd: tej tabeli już nie ma!

Jak tego uniknąć?

Przechowuj tymczasowe dane, które musisz używać między sesjami, w zwykłych tabelach albo dokumentuj ich użycie w ramach jednej sesji.

Błąd 7: Zapomniane ograniczenia podczas testowania

Często podczas developmentu możesz pominąć niektóre ograniczenia, myśląc "dorzucę je później". Ale jak pokazuje życie, "później" łatwo zapomnieć.

Przykład błędu:

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

-- Wstawiamy dane:
INSERT INTO test_table (name) VALUES ('Duplicate Name');
INSERT INTO test_table (name) VALUES ('Duplicate Name'); -- Problemy się zaczynają...

Jak tego uniknąć?

Od razu twórz tabele z ograniczeniami, nawet na etapie testów:

CREATE TABLE test_table (
    id SERIAL PRIMARY KEY,
    name VARCHAR(50) UNIQUE -- Oszczędzi Ci bólu głowy
);