Database per principianti: guida a SQL, Postgres e Supabase

Perché le applicazioni web hanno bisogno dei database

Un'applicazione può mostrare una schermata, raccogliere informazioni o eseguire un'azione. Ma cosa succede quando deve ricordare qualcosa?

Una piattaforma di prenotazione deve ricordare clienti, servizi e appuntamenti. Un negozio e-commerce deve gestire prodotti, ordini e inventario. Una piattaforma SaaS deve sapere quali utenti hanno un account, quali progetti hanno creato e quali autorizzazioni possiedono.

È per questo che esistono i database.

Un database è il luogo in cui un'applicazione archivia in modo strutturato e persistente le informazioni di cui ha bisogno. Senza un database, molti di questi dati potrebbero esistere solo temporaneamente nel browser. Una volta chiusa la pagina, potrebbero andare persi. Con un database, l'app può salvare le informazioni e recuperarle in seguito, da dispositivi diversi e per utenti differenti.

Un database è la memoria dell'app

Puoi considerare il database come la memoria permanente di un'applicazione.

Il frontend mostra le informazioni. Il backend applica la logica. Il database archivia i dati.

In un'app di prenotazione, per esempio:

Frontend → mostra i servizi e il calendario Backend → verifica disponibilità e autorizzazioni Database → archivia utenti, servizi e prenotazioni

Esistono diversi tipi di database. I database a documenti utilizzano documenti flessibili, quelli chiave-valore sono ottimizzati per determinati tipi di accesso rapido, mentre i database relazionali organizzano i dati in tabelle collegate tra loro. SQL e Postgres appartengono principalmente a quest'ultimo mondo. Supabase, invece, offre una raccolta di servizi backend per applicazioni web basati su Postgres.

Database relazionali: tabelle, righe e relazioni

Un database relazionale organizza le informazioni in tabelle. In genere, ogni tabella rappresenta un tipo di entità. In una piattaforma di prenotazione potresti avere:

• profiles → utenti;
• services → servizi disponibili;
• bookings → prenotazioni.

All'interno di ogni tabella troverai:

• colonne, che descrivono le proprietà dei dati;
• righe, che rappresentano i singoli record;
• chiavi primarie, che identificano in modo univoco ogni record;
• chiavi esterne, che collegano record appartenenti a tabelle diverse;
• vincoli, che impediscono il salvataggio di dati non validi.

Per esempio, una prenotazione potrebbe contenere un profile_id e un service_id. In questo modo sai esattamente chi ha effettuato la prenotazione e quale servizio ha scelto, senza dover copiare tutte le informazioni dell'utente e del servizio in ogni singola prenotazione.

Perché le relazioni sono importanti?

Immagina che un servizio cambi nome. Se il nome fosse copiato in ogni prenotazione, dovresti aggiornare centinaia o migliaia di record. Con un database relazionale, la prenotazione può semplicemente fare riferimento al servizio corretto. Le relazioni tra i dati aiutano quindi a ridurre duplicazioni e incoerenze, mantenendo più organizzato il modello del prodotto.

Che cos'è lo schema di un database?

Prima di creare un database, devi decidere come organizzare le informazioni. L'insieme di tabelle, colonne, relazioni, tipi di dati e vincoli che definisce questa struttura prende il nome di schema. Progettare bene lo schema significa fare in modo che il database rispecchi il reale funzionamento del prodotto.

Prima di creare una nuova tabella, chiediti:

1. Che cosa rappresenta ogni record?
2. Quali informazioni sono obbligatorie?
3. Quali valori devono essere univoci?
4. Quali entità devono essere collegate?
5. Chi può leggere o modificare questi dati?

L'obiettivo non è creare il maggior numero possibile di tabelle. Un'unica tabella enorme contenente tipi di informazioni completamente diversi può diventare difficile da gestire. Allo stesso tempo, inserire ogni piccolo dato in una tabella separata può rendere il sistema inutilmente complesso.

Un buono schema bilancia coerenza dei dati, semplicità delle query e reali requisiti del prodotto.

Che cos'è SQL?

È qui che entra in gioco SQL, abbreviazione di Structured Query Language. SQL è il linguaggio utilizzato per interagire con molti database relazionali.

Puoi usarlo per:

• creare strutture;
• leggere dati;
• aggiungere record;
• modificare informazioni;
• eliminare record;
• collegare dati provenienti da tabelle diverse.

Le quattro operazioni fondamentali vengono spesso riassunte con l'acronimo CRUD:

• Create → creare
• Read → leggere
• Update → aggiornare
• Delete → eliminare

Un semplice esempio

Supponiamo di voler recuperare le prenotazioni effettuate da uno specifico utente. Una query SQL potrebbe essere simile a questa:

SELECT id, start_time, status
FROM bookings
WHERE profile_id = 42
ORDER BY start_time;

In termini pratici, stiamo dicendo:

“Restituisci gli ID, gli orari e gli stati delle prenotazioni dell'utente 42, ordinati per orario.”

SQL può anche combinare informazioni provenienti da tabelle diverse. Per esempio:

SELECT bookings.start_time, services.name
FROM bookings
JOIN services ON services.id = bookings.service_id;

Questa query collega le prenotazioni ai servizi corrispondenti, così da restituire il nome del servizio insieme all'orario della prenotazione.

SQL è dichiarativo

Una caratteristica importante di SQL è il fatto che si tratta di un linguaggio dichiarativo. Non devi necessariamente specificare ogni singolo passaggio che il database deve eseguire per trovare un'informazione. Gli indichi quale risultato desideri e il database decide come eseguire la query.

SQL è inoltre uno standard molto diffuso, anche se i diversi sistemi possono offrire funzionalità ed estensioni specifiche. Non serve imparare tutto subito. Comprendere concetti come SELECT, filtri, JOIN, raggruppamenti, vincoli e transazioni è già sufficiente per costruire basi solide.

Che cos'è Postgres?

È importante fare una distinzione: SQL è il linguaggio. Postgres è il database.

Postgres, o più precisamente PostgreSQL, è un sistema open source per la gestione di database relazionali. È il software che archivia i dati, applica i vincoli e interpreta le query SQL.

Puoi rappresentare questa relazione nel modo seguente:

SQL → il linguaggio che usi per comunicare Postgres → il sistema che archivia e gestisce i dati

Postgres supporta funzionalità essenziali come:

• chiavi primarie e chiavi esterne
• transazioni
• indici
• viste
• vincoli
• tipi di dati avanzati

Perché le transazioni sono importanti?

Immagina un negozio e-commerce. Quando un cliente acquista un prodotto, il sistema potrebbe dover:

1. creare l'ordine;
2. ridurre l'inventario;
3. registrare il pagamento.

Queste operazioni sono collegate. Se la prima va a buon fine ma la seconda fallisce, potresti ritrovarti con un ordine registrato e un inventario mai aggiornato.

Le transazioni consentono di trattare più operazioni come un'unica unità: o vengono completate tutte con successo, oppure il database può ripristinare lo stato precedente.

E gli indici?

Gli indici rendono più veloci determinate ricerche. Se un'applicazione deve trovare ripetutamente le prenotazioni di un utente in una data specifica, un indice può rendere l'operazione molto più efficiente. Gli indici, però, hanno un costo: occupano spazio e richiedono operazioni aggiuntive ogni volta che i dati vengono modificati.

Per questo, indicizzare automaticamente ogni colonna non è una buona pratica. Un indice dovrebbe rispondere a un modello di query realmente utilizzato nel prodotto.

Che cos'è Supabase?

Se Postgres è il database, Supabase è una piattaforma backend costruita attorno a Postgres. Non sostituisce Postgres.

Aggiunge invece una serie di servizi comunemente necessari per sviluppare applicazioni web, tra cui:

• autenticazione e gestione delle sessioni;
• archiviazione dei file;
• strumenti di amministrazione del database;
• funzioni lato server;
• API per i dati;
• Row Level Security.

La distinzione più importante da ricordare è:

SQL è il linguaggio. Postgres è il database. Supabase è una piattaforma backend che utilizza Postgres e aggiunge servizi per sviluppare applicazioni.

Questa combinazione è particolarmente utile per le app web perché permette di gestire dati, utenti, file e autorizzazioni all'interno di un'infrastruttura integrata.

Autenticazione e autorizzazione: due concetti diversi

Anche in questo caso è utile distinguere due concetti. Autenticazione significa:

“Chi è questo utente?”

Autorizzazione significa:

“Che cosa può fare questo utente?”

Supabase Auth può gestire registrazione, accesso e sessioni. La Row Level Security (RLS) può stabilire quali righe del database un determinato utente è autorizzato a leggere o modificare. Immagina una piattaforma di prenotazione. Un cliente dovrebbe poter vedere:

le proprie prenotazioni.

Un amministratore, invece, potrebbe essere autorizzato a vedere:

tutte le prenotazioni.

Entrambi sono utenti autenticati, ma dispongono di autorizzazioni differenti.

La sicurezza non può dipendere solo dal frontend

Nascondere un pulsante nell'interfaccia non impedisce a qualcuno di eseguire un'operazione. Un utente potrebbe provare a inviare una richiesta direttamente al backend.

Per questo motivo, le regole di accesso devono essere applicate nel backend e nel database, non soltanto nell'interfaccia. È qui che la Row Level Security diventa importante: permette di definire le regole di accesso direttamente a livello di database.

Come funzionano i database in Coderblock

Nelle applicazioni web standard di Coderblock, ogni progetto dispone di un ambiente Supabase dedicato con Postgres, Auth, Storage, Deno Edge Functions e Row Level Security. Sono inclusi per impostazione predefinita anche una struttura di base per i profili e un sistema iniziale di ruoli.

La differenza è che non devi necessariamente iniziare configurando il database manualmente. Puoi descrivere nella chat ciò che vuoi sviluppare.

Per esempio:

“Aggiungi servizi con durata, prezzo e stato attivo.”

Poi:

“Crea prenotazioni collegate agli utenti autenticati.”

E infine:

“Impedisci ai clienti di vedere le prenotazioni degli altri clienti e crea una vista amministrativa per gestirle tutte.”

L'agente può progettare lo schema, applicare le migrazioni, collegare il frontend React al backend e configurare le policy RLS necessarie. Nella sezione Backend dell'editor puoi quindi esaminare tabelle, utenti autenticati, spazio di archiviazione e funzioni.

L'anteprima in tempo reale si aggiorna mentre continui a modificare l'app attraverso la conversazione.

Il prompt migliore non è “crea un database”

Quando utilizzi uno strumento di sviluppo di app basato sull'AI, non è sufficiente chiedere:

“Crea un database per un'app di prenotazione.”

È molto più utile descrivere il modello del prodotto. Specifica:

• le entità principali;
• quali informazioni devono contenere;
• come sono collegate;
• quali campi sono obbligatori;
• quali utenti possono accedere ai dati;
• quali azioni possono eseguire.

In questo modo fornisci all'AI le informazioni necessarie per trasformare la descrizione di un prodotto in una struttura dati coerente.

Buone pratiche per chi inizia a usare i database

Non devi essere un database engineer per evitare gli errori più comuni.

Usa identificatori stabili

Ogni tabella importante dovrebbe avere una chiave primaria. Evita di usare dati come nomi o indirizzi email come identificatori permanenti, perché possono cambiare.

Mantieni le regole vicine ai dati

La validazione nel frontend è utile per l'esperienza utente, ma non dovrebbe essere l'unica misura di protezione. Usa:

• campi obbligatori;
• vincoli di unicità;
• chiavi esterne;
• tipi di dati appropriati;
• policy di accesso.

Ciò consente al database di proteggere l'integrità dei dati indipendentemente dall'origine di una richiesta.

Segui il principio del privilegio minimo

Ogni utente dovrebbe disporre soltanto delle autorizzazioni necessarie per svolgere le proprie attività. Testa l'app con ruoli diversi:

• visitatore anonimo;
• utente autenticato;
• amministratore.

Verifica sempre quali dati ogni ruolo può leggere, creare, modificare o eliminare.

Gestisci lo schema tramite migrazioni

I database cambiano insieme ai prodotti. Quando aggiungi una nuova funzionalità, potresti dover creare una tabella, aggiungere una colonna o modificare una relazione. L'uso di migrazioni controllate permette di tenere traccia di questi cambiamenti e riduce il rischio di perdere i dati esistenti. Prima di eliminare una colonna o modificare una struttura, assicurati sempre che non sia più utilizzata.

Modella il prodotto, non la schermata

Questa potrebbe essere la regola più importante. Una tabella dovrebbe rappresentare un concetto reale del prodotto, non semplicemente una schermata dell'interfaccia. Il design di una dashboard può cambiare completamente. Un cliente, una prenotazione o un ordine continuano invece a rappresentare la stessa entità. Pensare prima al modello dei dati rende anche più semplice far evolvere il frontend in futuro.

SQL, Postgres e Supabase: ciò che devi davvero ricordare

Se sei agli inizi, non devi memorizzare decine di termini.

Tieni a mente questa relazione:

SQL → il linguaggio usato per interrogare e modificare i dati Postgres → il database relazionale che archivia i dati ed esegue le query Supabase → la piattaforma backend che utilizza Postgres e aggiunge autenticazione, archiviazione, API, funzioni e strumenti per sviluppare applicazioni web

In Coderblock, questi concetti sono integrati nel processo di sviluppo dell'app. Puoi descrivere in linguaggio naturale che cosa deve ricordare la tua applicazione, come devono essere collegati i dati e chi può accedervi. L'agente può occuparsi dell'intera implementazione full-stack, mentre tu controlli e perfezioni il risultato tramite la chat.

Capire come funzionano i database ti aiuta quindi a fare qualcosa di ancora più importante: descrivere con maggiore chiarezza ciò che vuoi sviluppare. Non devi necessariamente scrivere codice SQL. Sapere che cosa sono tabelle, relazioni, ruoli, vincoli e autorizzazioni, però, ti aiuterà a trasformare un'idea in un'applicazione che non si limita a mostrare i dati, ma può davvero archiviarli, collegarli e proteggerli.