Database e Tabelle
Bentornato.
Nella lezione precedente hai installato PostgreSQL, aperto psql, creato il tuo primo database, creato la tua prima tabella, inserito dati ed eseguito la tua prima SELECT.
Questo è già lavoro reale con database.
Piccolo.
Ma reale.
Oggi rallentiamo e guardiamo una cosa estremamente importante:
Database e tabelle.
Sì.
I nomi sembrano semplici.
Ma è qui che nascono molti problemi futuri.
Una cattiva struttura di tabella è come un garage disordinato.
All’inizio sembra tutto normale.
Poi un giorno ti serve un cavo.
E improvvisamente stai combattendo con una vecchia bicicletta, tre scatole e una sedia misteriosa che nessuno ricorda di aver comprato.
In PostgreSQL, la struttura conta.
Tantissimo.
Cosa Imparerai
In questa lezione imparerai:
- che cos’è un database;
- che cos’è una tabella;
- come funzionano righe e colonne;
- che cosa sono i record;
- come pensare al design delle tabelle;
- come scegliere buoni nomi per le tabelle;
- come scegliere buoni nomi per le colonne;
- come creare più tabelle;
- come ispezionare la struttura di una tabella;
- come eliminare tabelle con attenzione;
- come evitare errori comuni di design.
Alla fine di questa lezione capirai come PostgreSQL organizza i dati.
Non solo come digitare comandi.
Inizierai a pensare come uno sviluppatore di database.
Leggermente pericoloso.
Molto utile.
Database vs Tabella
Un database è un contenitore.
Una tabella è dove vivono i dati strutturati veri.
Esempio:
Database: learning_postgresql
Tabelle:
students
books
courses
Il database contiene tabelle.
Le tabelle contengono righe.
Le righe contengono dati reali.
Pensala così:
Database = casa
Tabella = stanza
Riga = oggetto dentro la stanza
Colonna = dettaglio dell’oggetto
Per esempio, in una tabella students:
id | name | age | email
---|--------|-----|-------------------
1 | Anna | 22 | anna@example.com
2 | Marco | 28 | marco@example.com
La tabella è students.
Ogni riga è uno studente.
Ogni colonna descrive qualcosa dello studente.
Idea semplice.
Molto potente.
Anche molto facile da rendere disordinata se non fai attenzione.
Come i cavi dietro una scrivania.
Righe e Colonne
Una tabella ha colonne e righe.
Le colonne definiscono la struttura.
Le righe contengono i dati.
Esempio:
tabella products
id | name | price | available
---|----------|-------|----------
1 | Laptop | 900 | true
2 | Mouse | 25 | true
3 | Keyboard | 70 | false
Colonne:
id;name;price;available.
Righe:
- riga Laptop;
- riga Mouse;
- riga Keyboard.
Una colonna dice che tipo di informazione può essere salvata.
Una riga salva un elemento reale.
Questo è importante.
Non creare una nuova colonna per ogni nuovo elemento.
Cattiva idea:
student1 | student2 | student3
---------|----------|---------
Anna | Marco | Viktor
Idea migliore:
id | name
---|--------
1 | Anna
2 | Marco
3 | Viktor
Le righe sono per i record.
Le colonne sono per le proprietà.
Questa regola salva vite.
Vite da database.
Comunque importante.
Che Cos'è un Record?
Un record è una riga in una tabella.
In questa tabella:
students
id | name | age
---|--------|----
1 | Anna | 22
2 | Marco | 28
Anna è un record.
Marco è un altro record.
Un record di solito rappresenta una cosa:
- un utente;
- un prodotto;
- un ordine;
- un libro;
- un corso;
- un’attività.
Se la tabella si chiama books, una riga dovrebbe essere un libro.
Se la tabella si chiama users, una riga dovrebbe essere un utente.
Se la tabella si chiama orders, una riga dovrebbe essere un ordine.
Sembra ovvio.
Ma il caos nei database spesso inizia quando una riga prova a rappresentare troppe cose.
Una riga non dovrebbe provare a essere un utente, un ordine, un pagamento e una ricevuta della pizza.
Anche PostgreSQL ha dei limiti.
Emotivamente.
Connettiti al Database
Apri PostgreSQL:
sudo -iu postgres psql
Connettiti al database della lezione 1:
\c learning_postgresql
Se non esiste, crealo:
CREATE DATABASE learning_postgresql;
Poi connettiti:
\c learning_postgresql
Ora sei pronto.
La porta del database è aperta.
Per favore non correre contro i mobili.
Elencare le Tabelle
Per elencare le tabelle nel database corrente, esegui:
\dt
Potresti vedere:
students
Se hai creato la tabella nella lezione 1.
Se non vedi tabelle, va bene.
Database vuoto.
Nuovo inizio.
Come un quaderno nuovo.
Bellissimo.
Leggermente intimidatorio.
Creare una Tabella Books
Creiamo una nuova tabella chiamata books.
CREATE TABLE books (
id SERIAL PRIMARY KEY,
title VARCHAR(150) NOT NULL,
author VARCHAR(100),
year_published INTEGER
);
Questa tabella ha:
id;title;author;year_published.
Ora elenca le tabelle:
\dt
Dovresti vedere:
books
students
Ora abbiamo più di una tabella.
Il database sta diventando una piccola biblioteca.
Molto professionale.
Quasi.
Ispezionare la Struttura della Tabella
Per ispezionare la tabella books, esegui:
\d books
PostgreSQL mostrerà la struttura della tabella.
Vedrai nomi delle colonne, tipi di dati e vincoli.
Qualcosa tipo:
id | integer
title | character varying(150)
author | character varying(100)
year_published | integer
Questo è utile quando dimentichi quali colonne hai creato.
E dimenticherai.
Nessuna vergogna.
I database ricordano perché gli esseri umani no.
Questo è l’accordo.
Inserire Libri
Ora inserisci alcuni libri:
INSERT INTO books (title, author, year_published)
VALUES ('Clean Code', 'Robert C. Martin', 2008);
INSERT INTO books (title, author, year_published)
VALUES ('The Pragmatic Programmer', 'Andrew Hunt', 1999);
INSERT INTO books (title, author, year_published)
VALUES ('Database Design for Mere Mortals', 'Michael J. Hernandez', 2013);
Ora leggi i dati:
SELECT * FROM books;
Dovresti vedere i tuoi libri.
La tabella non è più vuota.
Ha dati.
Una tabella senza righe è solo un piano.
Una tabella con righe è dove inizia la storia.
Molto poetico.
Per SQL.
Nominare le Tabelle
I buoni nomi contano.
Il nome di una tabella dovrebbe descrivere cosa contiene.
Buoni nomi:
students
books
products
orders
customers
courses
Nomi cattivi:
data
stuff
things
my_table
table1
new_table_final_final_real
Non nominare le tabelle come nomini i file d’emergenza sul desktop.
PostgreSQL merita di meglio.
Anche tu.
Usa nomi chiari.
In questo corso useremo spesso nomi di tabelle al plurale:
students
books
orders
products
Perché al plurale?
Perché la tabella contiene molti record.
Una tabella students contiene molti studenti.
Semplice.
Leggibile.
Non tutti sono d’accordo su plurale vs singolare.
Va bene.
La cosa importante è la coerenza.
Scegli uno stile.
Usalo ovunque.
Non creare student, books, order_table e tbl_products nello stesso database.
Quello non è design.
È zuppa.
Nominare le Colonne
Anche i nomi delle colonne devono essere chiari.
Buoni nomi:
id
title
author
email
created_at
year_published
price
is_active
Nomi cattivi:
x
value
data1
thing
info
abc
Un nome di colonna dovrebbe rispondere:
Cosa viene salvato qui?
Esempio:
CREATE TABLE courses (
id SERIAL PRIMARY KEY,
title VARCHAR(150) NOT NULL,
description TEXT,
price INTEGER
);
Questo è leggibile.
Puoi capire cosa contiene la tabella.
Il tuo io futuro apprezzerà.
Il tuo io futuro è già stanco.
Aiutalo.
Usa snake_case
In PostgreSQL è comune usare snake_case.
Bene:
year_published
created_at
first_name
last_name
is_active
Evita spazi:
year published
first name
Evita mixed case:
yearPublished
FirstName
PostgreSQL può gestire nomi mixed-case tra virgolette, ma diventa fastidioso rapidamente.
Esempio fastidioso:
SELECT "FirstName" FROM users;
No grazie.
Usa snake_case minuscolo.
Il database sarà più pulito.
Le query saranno più facili.
Il debugging futuro conterrà meno lacrime.
Una Tabella, Un Argomento
Una tabella dovrebbe di solito salvare un tipo di cosa.
Bene:
students
courses
teachers
Male:
students_and_courses_and_teachers
Perché?
Perché cose diverse hanno dati diversi.
Uno studente ha:
- nome;
- email;
- età.
Un corso ha:
- titolo;
- descrizione;
- prezzo.
Un insegnante ha:
- nome;
- materia;
- email.
Non mischiare tutto in una tabella gigante.
Una tabella gigante sembra facile all’inizio.
Poi diventa un mostro.
E non un mostro carino.
Un mostro spreadsheet.
Terrificante.
Creare una Tabella Courses
Ora crea un’altra tabella:
CREATE TABLE courses (
id SERIAL PRIMARY KEY,
title VARCHAR(150) NOT NULL,
description TEXT,
price INTEGER
);
Inserisci alcuni corsi:
INSERT INTO courses (title, description, price)
VALUES ('PostgreSQL Basics', 'Learn database fundamentals with PostgreSQL.', 49);
INSERT INTO courses (title, description, price)
VALUES ('JavaScript Basics', 'Learn JavaScript from the beginning.', 59);
INSERT INTO courses (title, description, price)
VALUES ('HTML and CSS', 'Build clean web pages with HTML and CSS.', 39);
Leggi i dati:
SELECT * FROM courses;
Ora il tuo database ha almeno tre possibili tabelle:
students
books
courses
Ogni tabella ha il suo argomento.
Bene.
Pulito.
Approvato dal database.
Probabilmente.
I Tipi di Dati Contano
Ogni colonna ha un tipo di dato.
Esempio:
title VARCHAR(150)
price INTEGER
description TEXT
Il tipo di dato dice a PostgreSQL che tipo di valore può andare nella colonna.
Per esempio:
price INTEGER
significa che il prezzo dovrebbe essere un numero.
Questo è buono.
Perché i database devono proteggere la struttura.
Se lasci che ogni colonna accetti qualsiasi cosa, il caos arriva con gli occhiali da sole.
Impareremo meglio i tipi di dati più avanti.
Per ora ricorda:
Usa colonne testuali per il testo.
Usa colonne numeriche per i numeri.
Usa colonne boolean per true o false.
Usa date per le date.
Non salvare tutto come testo.
Quella è la versione database di mettere tutti gli attrezzi in una scatola e chiamarla organizzazione.
NULL e NOT NULL
Una colonna può permettere valori vuoti.
In SQL, un valore vuoto o mancante si chiama NULL.
Esempio:
CREATE TABLE teachers (
id SERIAL PRIMARY KEY,
name VARCHAR(100) NOT NULL,
email VARCHAR(150),
subject VARCHAR(100)
);
Qui:
name VARCHAR(100) NOT NULL
significa che il nome è obbligatorio.
Ma:
email VARCHAR(150)
può essere vuoto.
Quindi questo funziona:
INSERT INTO teachers (name, subject)
VALUES ('Laura', 'Databases');
Perché email non è obbligatorio.
Ma questo non funziona:
INSERT INTO teachers (email, subject)
VALUES ('laura@example.com', 'Databases');
Perché?
Perché name è obbligatorio.
PostgreSQL protegge la regola.
Molto severo.
Molto utile.
Come un cane da guardia con conoscenza SQL.
Creare una Tabella Teachers
Crea una tabella:
CREATE TABLE teachers (
id SERIAL PRIMARY KEY,
name VARCHAR(100) NOT NULL,
email VARCHAR(150),
subject VARCHAR(100)
);
Inserisci dati:
INSERT INTO teachers (name, email, subject)
VALUES ('Laura', 'laura@example.com', 'Databases');
INSERT INTO teachers (name, subject)
VALUES ('Paolo', 'Web Development');
Ora leggi:
SELECT * FROM teachers;
Dovresti vedere che Paolo non ha email.
Quel valore mancante è NULL.
È permesso perché la colonna email non ha NOT NULL.
Questo è design della tabella.
Tu decidi cosa è obbligatorio.
PostgreSQL lo fa rispettare.
Tu sei l’architetto.
PostgreSQL è il costruttore serio.
Eliminare una Tabella
A volte devi eliminare una tabella.
Fai attenzione.
Questo rimuove la tabella e i suoi dati.
Esempio:
DROP TABLE teachers;
PostgreSQL eliminerà la tabella.
Per sempre.
Nessuna guarigione emotiva.
Per sicurezza puoi usare:
DROP TABLE IF EXISTS teachers;
Questo significa:
Elimina la tabella se esiste.
Se non esiste, non generare errore.
Non eliminare tabelle a caso.
Questo non è un gioco.
Beh, è un corso.
Ma comunque.
Rispetta DROP.
Ha potere.
Troppo potere per una parola di quattro lettere.
Ricreare una Tabella
Se hai eliminato teachers, puoi ricrearla:
CREATE TABLE teachers (
id SERIAL PRIMARY KEY,
name VARCHAR(100) NOT NULL,
email VARCHAR(150),
subject VARCHAR(100)
);
Questo è utile per esercitarsi.
Durante l’apprendimento va bene creare ed eliminare tabelle di test.
Ma non farlo in produzione.
I database di produzione non sono parchi giochi.
Sono più simili a musei con elettricità.
Tocca con attenzione.
Errori Comuni di Design
Una Tabella Gigante
Cattiva idea:
users_orders_products_payments
Una tabella per tutto.
Diventa difficile da leggere, aggiornare e capire.
Meglio:
users
orders
products
payments
Tabelle separate per cose separate.
Struttura pulita.
Meno pianti.
Nomi di Colonne Cattivi
Male:
n
em
val
thing1
thing2
Meglio:
name
email
price
created_at
Nomi chiari rendono SQL più facile.
Nomi poco chiari fanno arrabbiare il tuo io futuro.
E il tuo io futuro sa dove abiti.
Salvare Liste in una Colonna
Male:
student_name | courses
-------------|-------------------------------
Anna | PostgreSQL, JavaScript, HTML
Sembra facile.
Ma dopo diventa difficile cercare, aggiornare e collegare i dati.
Un design migliore usa tabelle separate.
Impareremo le relazioni più avanti.
Per ora ricorda:
Se un valore contiene una lista, forse vuole un’altra tabella.
I database sussurrano queste cose.
Ascolta bene.
Pratica
Crea una tabella chiamata movies.
Deve avere:
id;title;director;year_released;rating.
Esempio:
CREATE TABLE movies (
id SERIAL PRIMARY KEY,
title VARCHAR(150) NOT NULL,
director VARCHAR(100),
year_released INTEGER,
rating INTEGER
);
Inserisci tre film:
INSERT INTO movies (title, director, year_released, rating)
VALUES ('Inception', 'Christopher Nolan', 2010, 9);
Leggi tutti i film:
SELECT * FROM movies;
Poi ispeziona la tabella:
\d movies
Poi elenca tutte le tabelle:
\dt
Questo ti aiuterà a praticare:
- creazione di una tabella;
- scelta delle colonne;
- inserimento di righe;
- lettura di righe;
- ispezione della struttura.
Molto pratico.
Molto SQL.
Mini Challenge
Crea una piccola struttura database per una piattaforma di apprendimento.
Ti servono tre tabelle:
students
courses
teachers
Ogni tabella deve avere almeno tre colonne.
Esempio:
students:
id
name
email
courses:
id
title
price
teachers:
id
name
subject
Crea le tabelle.
Inserisci almeno due righe in ogni tabella.
Poi esegui:
SELECT * FROM students;
SELECT * FROM courses;
SELECT * FROM teachers;
È ancora semplice.
Ma ora stai pensando in termini di struttura database.
Non solo comandi.
Questo è l’obiettivo.
Riepilogo
Oggi hai imparato:
- un database contiene tabelle;
- le tabelle contengono righe e colonne;
- una riga è anche chiamata record;
- ogni tabella dovrebbe salvare un tipo di cosa;
- buoni nomi di tabella sono chiari e coerenti;
- buoni nomi di colonna descrivono i dati;
snake_caseè un buon stile di naming;- i tipi di dati definiscono che valore salva una colonna;
NULLsignifica valore mancante;NOT NULLrende una colonna obbligatoria;\dtelenca le tabelle;\d table_namemostra la struttura della tabella;DROP TABLEelimina una tabella e i suoi dati;- una buona struttura previene il caos futuro.
Questa lezione può sembrare semplice.
Ma è estremamente importante.
Un cattivo design di database crea problemi che lentamente mettono i denti.
Un buon design rende le query future più facili, sicure e pulite.
PostgreSQL è potente.
Ma non può salvarti da una tabella chiamata stuff.
Sii gentile con il tuo database.
Dai nomi corretti.
Struttura con chiarezza.
Il tuo io futuro non ti manderà messaggi arrabbiati.
Forse.
Prossima Lezione
Nella prossima lezione impareremo i comandi SQL di base:
SELECT;INSERT;UPDATE;DELETE.
Queste sono le azioni principali per lavorare con i dati.
Leggere.
Creare.
Modificare.
Rimuovere.
Il ciclo della vita del database.
Con punti e virgola.