Database
L’insieme organizzato dei dati e delle relative regole.
Dal problema aziendale alla capacità tecnica
SQL non serve solo a leggere dati.
Scopri come un database relazionale può strutturare, controllare, modificare, automatizzare, proteggere e accelerare le informazioni di un’organizzazione.
Pratica disponibileSpiegazione disponibileLaboratorio in preparazione
Quattro concetti diversi
Linguaggio, dati e software non sono sinonimi.
DBMS
Il software che memorizza, controlla ed esegue le operazioni.
Server
L’ambiente che esegue un servizio di database per i client.
SQL
Il linguaggio usato da più DBMS, con una base comune e dialetti.
PostgreSQL, MySQL e SQL Server sono DBMS. Usano SQL, ma tipi, funzioni, procedure, strumenti di amministrazione e alcune sintassi differiscono.
12 famiglie
Parti dal problema, poi scegli lo strumento.
Spiegazione disponibilePrincipiante
Modellare
- Problema aziendale
- Clienti, ordini e pagamenti sono mescolati o copiati più volte.
- Spiegazione semplice
- Tabelle, tipi, schemi, chiavi e relazioni danno posto e significato a ogni fatto.
- Esempio
- Un ordine conserva id_client invece di copiare nome e indirizzo del cliente.
- Dialetto
- SQL comune; tipi dettagliati per DBMS
Pratica disponibileDa principiante ad avanzato
Interrogare
- Problema aziendale
- Un team vuole una risposta riproducibile invece di un totale calcolato a mano.
- Spiegazione semplice
- SELECT, filtri, aggregazioni, join, funzioni finestra e CTE trasformano una domanda in un risultato.
- Esempio
- Calcolare il fatturato per città e classificare il risultato più alto.
- Dialetto
- Ampia base SQL comune
Spiegazione disponibilePrincipiante / intermedio
Modificare
- Problema aziendale
- Un’applicazione deve registrare una vendita, correggere un indirizzo o eliminare una bozza.
- Spiegazione semplice
- INSERT aggiunge, UPDATE modifica e DELETE elimina; UPSERT o MERGE gestisce i conflitti secondo il sistema.
- Esempio
- Aggiornare il telefono del cliente identificato senza toccare altre righe.
- Dialetto
- INSERT/UPDATE/DELETE comuni; UPSERT/MERGE dipende dal dialetto
Spiegazione disponibilePrincipiante / intermedio
Garantire l’integrità
- Problema aziendale
- Un prezzo negativo, un’e-mail duplicata o un ordine orfano entra nel database.
- Spiegazione semplice
- Tipi, NOT NULL, UNIQUE, CHECK, PRIMARY KEY e FOREIGN KEY rifiutano gli stati non validi nel punto giusto.
- Esempio
- CHECK (prix >= 0) rifiuta un prezzo negativo prima che lo scopra un report.
- Dialetto
- SQL comune con sfumature
Laboratorio in preparazioneIntermedio
Gestire le transazioni
- Problema aziendale
- Un ordine viene creato ma il pagamento fallisce, lasciando dati incompleti.
- Spiegazione semplice
- Una transazione raggruppa le modifiche; COMMIT conferma, ROLLBACK annulla e SAVEPOINT permette un recupero parziale.
- Esempio
- Registrare insieme ordine e pagamento, oppure nessuno dei due.
- Dialetto
- Base SQL; isolamento e concorrenza dipendono dal DBMS
Spiegazione disponibileIntermedio
Creare viste
- Problema aziendale
- Tre report definiscono diversamente lo stesso fatturato mensile.
- Spiegazione semplice
- Una vista nomina una query riutilizzabile; una vista materializzata conserva un risultato da aggiornare.
- Esempio
- Esporre ventes_mensuelles a più strumenti senza copiare la query.
- Dialetto
- Viste ampiamente comuni; materializzazione secondo il sistema
Laboratorio in preparazioneIntermedio / avanzato
Automatizzare con funzioni, procedure e trigger
- Problema aziendale
- Ogni modifica di prezzo deve lasciare una traccia, qualunque sia il processo chiamante.
- Spiegazione semplice
- Una funzione incapsula un calcolo, una procedura esegue un’operazione e un trigger reagisce a un evento di tabella.
- Esempio
- Dopo UPDATE del prezzo, salvare OLD.prix e NEW.prix in una tabella storica.
- Dialetto
- Molto dipendente dal DBMS; esempi futuri PostgreSQL
Spiegazione disponibileIntermedio
Ottimizzare con indici ed EXPLAIN
- Problema aziendale
- La ricerca di un account per e-mail rallenta con la crescita della tabella.
- Spiegazione semplice
- EXPLAIN mostra il piano scelto; un indice può accelerare la lettura aggiungendo costi di spazio e scrittura.
- Esempio
- Confrontare il piano prima e dopo un indice su lower(email).
- Dialetto
- Principi comuni; piani specifici del DBMS
Spiegazione disponibileIntermedio
Proteggere con ruoli e permessi
- Problema aziendale
- Uno strumento di reporting deve leggere alcune viste senza modificare le tabelle.
- Spiegazione semplice
- Utenti, ruoli, GRANT, REVOKE e talvolta sicurezza a livello di riga applicano il privilegio minimo.
- Esempio
- Concedere SELECT su una vista al ruolo reporting e negare UPDATE sulla tabella sorgente.
- Dialetto
- SQL + amministrazione; RLS dipende dal DBMS
Spiegazione disponibileIntermedio / avanzato
Lavorare con JSON, testo o geografia
- Problema aziendale
- Alcuni dati sono semi-strutturati, testuali o spaziali.
- Spiegazione semplice
- JSON/JSONB, ricerca full-text, tipi geografici ed estensioni ampliano gli usi quando supportati.
- Esempio
- Conservare attributi variabili in JSONB indicizzando le chiavi più cercate.
- Dialetto
- Molto dipendente dal sistema e dalle estensioni
Spiegazione disponibileAvanzato
Amministrare, salvare e replicare
- Problema aziendale
- Il servizio deve poter essere ripristinato, monitorato e disponibile nonostante un guasto.
- Spiegazione semplice
- Backup, ripristino, replica, monitoraggio e alta disponibilità appartengono soprattutto all’amministrazione del DBMS e dell’infrastruttura.
- Esempio
- Provare un ripristino da dump invece di presumere che il backup funzioni.
- Dialetto
- Strumenti e procedure specifici del DBMS
Spiegazione disponibileDa principiante ad avanzato
Alimentare applicazioni e strumenti BI
- Problema aziendale
- Un’applicazione, un’API e Power BI devono usare definizioni coerenti.
- Spiegazione semplice
- SQL seleziona, controlla e prepara i dati; connettori, API e pipeline ETL/ELT li spostano o espongono.
- Esempio
- Preparare una vista alla granularità ordine per Power BI senza duplicare gli importi.
- Dialetto
- SQL in un’architettura più ampia
Scegli lo strumento più semplice
Quando non usare un trigger?
Basta un vincolo
Per rifiutare un prezzo negativo, CHECK è più visibile e diretto di una logica attivata.
La logica diventerebbe nascosta
Un trigger viene eseguito senza apparire nella query chiamante. Può sorprendere e complicare il debug.
Il volume è elevato
Un’azione per riga può rallentare una modifica massiva. Il costo va misurato sul caso reale.
La ricorsione è possibile
Un trigger che modifica la stessa tabella può richiamarsi. Servono progettazione e protezioni esplicite.
Casi adatti: audit, storicizzazione e alcune automazioni strettamente legate a un evento sui dati, dopo il confronto con un vincolo o la logica applicativa.
Parti da zero?
Inizia da una situazione senza codice ed esegui la prima query in meno di 45 minuti.