Errori tipici nella creazione e modifica delle tabelle

Ciao futuri guru di PostgreSQL! L’argomento di oggi riguarda forse una delle skill più preziose nella programmazione — evitare gli errori. Non si possono evitare proprio tutti, soprattutto se sei agli inizi con SQL. Ma imparare in fretta a riconoscere quelli tipici — si può fare. È come camminare al buio in una stanza piena di spigoli: ti fai male un paio di volte, ma poi sai dove sono le cose. E io ti aiuterò a schivare gli "spigoli" quando crei o modifichi le tabelle.

Errore 1: Scelta sbagliata del tipo di dato

Lavorare con i tipi di dato è come trovare la chiave giusta per una serratura. Una "chiave" sbagliata, cioè un tipo di dato non adatto, può far sì che la tabella funzioni male o sia meno efficiente.

Esempio di errore:

Vuoi creare una colonna per salvare numeri di telefono e per abitudine scegli il tipo INTEGER. Sembra logico, sono numeri, no? Ma il problema è che INTEGER non va bene per dati che:

• Iniziano con zero (0123456789 diventa solo 123456789).
• Contengono simboli come "+" o spazi.

-- Sbagliato:
CREATE TABLE customers (
    id SERIAL PRIMARY KEY,
    phone_number INTEGER -- Ops
);

-- Giusto:
CREATE TABLE customers (
    id SERIAL PRIMARY KEY,
    phone_number VARCHAR(15) -- Va bene per tutti i formati di numero
);

Come evitarlo?
Analizza bene la natura dei dati che vuoi salvare prima di scegliere il tipo di dato. Se hai dubbi, dai un’occhiata alla documentazione ufficiale di PostgreSQL sui tipi di dato.

Errore 2: Ignorare i constraint NOT NULL, CHECK, UNIQUE

I constraint aiutano a mantenere l’integrità dei dati. Se li dimentichi — nella tua tabella regnerà il caos, tipo valori vuoti dove non dovrebbero esserci.

Esempio di errore: Crei una tabella per salvare studenti, ma ti dimentichi che nome ed età sono obbligatori.

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

INSERT INTO students (name, age) VALUES (NULL, NULL); -- Ops, che roba è?!

Versione corretta:

CREATE TABLE students (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100) NOT NULL, -- Nome obbligatorio
    age INTEGER CHECK (age > 0) -- Età deve essere positiva
);

Come evitarlo?
Metti sempre i constraint sui campi obbligatori. Sono una specie di "meccanismo di sicurezza" che impedisce l’arrivo di dati problematici.

Errore 3: Problemi di unicità

A volte ti dimentichi di aggiungere il constraint di unicità UNIQUE su una colonna che dovrebbe avere solo valori unici. Così ti ritrovi con dati duplicati.

Esempio di errore: Crei una tabella per salvare indirizzi email, ma ti dimentichi di mettere UNIQUE.

-- Sbagliato:
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'); -- Questa email c'è già!

Versione corretta:

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

Come evitarlo?
Metti sempre UNIQUE se i valori devono essere unici. Se vuoi più flessibilità, puoi usare CONSTRAINT con un nome per identificare il constraint:

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

Errore 4: Errore nella modifica delle tabelle (ALTER TABLE)

Usare ALTER TABLE può essere insidioso, soprattutto se ci sono già dati nella tabella. Per esempio, puoi dimenticarti dei valori ammessi in una colonna e trovarti errori con i dati esistenti.

Esempio di errore: Vuoi aggiungere il constraint NOT NULL su una colonna già esistente, ma ci sono valori NULL nella colonna.

-- Sbagliato:
ALTER TABLE students ALTER COLUMN name SET NOT NULL; -- Errore!

Se nella tabella ci sono già righe con NULL, PostgreSQL non ti farà aggiungere il constraint.

Come fare?

Prima di aggiungere constraint, assicurati che i dati rispettino i requisiti. Per esempio:

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

Errore 5: Eliminare tabelle o dati senza controllare

Eliminare una tabella con DROP TABLE o dati con DELETE — è un’azione che non puoi annullare. Quindi prima di cancellare, controlla sempre cosa stai eliminando.

Esempio di errore:

DROP TABLE courses; -- Ops, non era la tabella giusta!

Come evitarlo?

Usa il comando \dt in psql per vedere quali tabelle esistono e assicurati di cancellare quella giusta.

Oppure usa DROP TABLE IF EXISTS per evitare errori se provi a cancellare una tabella che non esiste:

DROP TABLE IF EXISTS courses;

Errore 6: Problemi con le tabelle temporanee

Le tabelle temporanee spariscono alla fine della sessione. Se per sbaglio provi a usare una tabella temporanea dopo che la sessione è finita, ti becchi un errore.

Esempio di errore:

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

-- Hai chiuso la sessione, e ora...
SELECT * FROM temp_students; -- Errore: la tabella non esiste più!

Come evitarlo?

Salva i dati temporanei che ti servono tra sessioni in tabelle normali oppure documenta bene che vanno usate solo nella stessa sessione.

Errore 7: Dimenticare i constraint durante i test

Spesso durante lo sviluppo puoi saltare qualche constraint pensando "vabbè, lo aggiungo dopo". Ma, come spesso succede, "dopo" te lo dimentichi.

Esempio di errore:

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

-- Inseriamo dati:
INSERT INTO test_table (name) VALUES ('Nome Duplicato');
INSERT INTO test_table (name) VALUES ('Nome Duplicato'); -- E qui iniziano i problemi...

Come evitarlo?

Crea subito le tabelle con i constraint, anche quando stai solo testando:

CREATE TABLE test_table (
    id SERIAL PRIMARY KEY,
    name VARCHAR(50) UNIQUE -- Ti risparmia un sacco di mal di testa
);