Un database è una raccolta organizzata di dati progettata per poterli memorizzare, trovare, modificare e mettere in relazione in modo controllato. Dietro un e-commerce, un gestionale, un’app, un sistema di prenotazione o un sito WordPress c’è quasi sempre uno o più database che conservano le informazioni necessarie al funzionamento del servizio.
Il database, però, non è la stessa cosa del software che lo gestisce. Questo software prende il nome di DBMS, Database Management System: riceve le richieste delle applicazioni, legge e modifica i dati, controlla gli accessi e gestisce operazioni come query e transazioni.
Anche l’idea che tutti i database siano composti da tabelle è incompleta. Tabelle, righe, colonne e relazioni appartengono soprattutto al modello relazionale. Altri database organizzano le informazioni come documenti, coppie chiave-valore, grafi o strutture specializzate.
Capire queste differenze permette di vedere cosa succede realmente quando un’applicazione salva un ordine, recupera un cliente, verifica una disponibilità o cerca informazioni fra milioni di record.
Cos’è un database e a cosa serve
Un database, o base di dati, è un insieme strutturato di informazioni che può essere consultato e modificato secondo regole definite.
Pensiamo a un e-commerce. Per funzionare deve conservare dati molto diversi:
- prodotti;
- prezzi;
- disponibilità di magazzino;
- clienti;
- indirizzi;
- ordini;
- pagamenti;
- spedizioni.
Salvare semplicemente queste informazioni in file separati sarebbe possibile per un sistema molto piccolo, ma diventerebbe rapidamente difficile mantenerle coerenti.
Un database permette invece all’applicazione di porre domande precise ai dati:
- quali ordini appartengono a un determinato cliente?
- quali prodotti stanno terminando?
- quali ordini risultano ancora da spedire?
- quanto ha acquistato un cliente in un determinato periodo?
- quali prodotti compaiono nello stesso ordine?
Il valore di un database non consiste quindi soltanto nell’archiviazione, ma nella possibilità di mantenere informazioni organizzate, applicare regole e recuperare i dati necessari quando servono.
Una definizione simile è utilizzata anche da Oracle, che descrive il database come una raccolta organizzata di informazioni o dati generalmente conservata elettronicamente in un sistema informatico.
Database, DBMS e sistema di database: le differenze
I termini database e DBMS vengono spesso utilizzati come se fossero sinonimi, ma indicano componenti differenti.
Il database è l’insieme organizzato dei dati.
Il DBMS è il software che permette di creare, interrogare, aggiornare e amministrare quei dati.
MySQL e PostgreSQL, per esempio, sono DBMS relazionali. MongoDB è un sistema di gestione orientato ai documenti. Redis utilizza un modello molto diverso, centrato su strutture dati accessibili tramite chiavi.
Quando database, DBMS e applicazioni che li utilizzano vengono considerati insieme, si può parlare più precisamente di sistema di database.
La distinzione è importante perché evita un errore frequente: dire che “SQL è un database” o che “una tabella è un database”. SQL è un linguaggio utilizzato da molti sistemi relazionali; una tabella è invece una delle strutture attraverso cui un database relazionale organizza i dati.
AWS distingue allo stesso modo il sistema di gestione del database dai dati gestiti dal software.
Database e foglio di calcolo non sono la stessa cosa
Per spiegare un database relazionale si usa spesso Excel come analogia. È utile per visualizzare righe e colonne, ma un database non è semplicemente un foglio di calcolo più grande.
Un foglio elettronico è ottimo per calcoli, analisi manuali e raccolte di dati relativamente semplici. Un DBMS è progettato per esigenze differenti: molte applicazioni o utenti possono leggere e modificare dati, esistono regole di integrità, query, relazioni, indici, autorizzazioni e meccanismi per gestire operazioni concorrenti.
Immagina un e-commerce in cui due clienti tentano di acquistare contemporaneamente l’ultimo articolo disponibile. Il problema non consiste semplicemente nel modificare una cella da 1 a 0: il sistema deve coordinare più operazioni e impedire che il medesimo articolo venga venduto due volte.
È in situazioni come questa che concetti quali transazioni, vincoli e concorrenza diventano determinanti.
Come funziona un database
Un database funziona attraverso l’interazione fra dati, modello, DBMS e applicazione.
L’applicazione non deve normalmente cercare da sola i dati nei file fisici del server. Formula invece una richiesta al DBMS. Il sistema interpreta la richiesta, individua i dati, esegue le operazioni necessarie e restituisce il risultato.
In forma semplificata:
applicazione → richiesta/query → DBMS → dati → risultato → applicazione
Quando apri la pagina di un prodotto, per esempio, l’applicazione può richiedere identificativo, nome, prezzo, disponibilità e altre informazioni. Il DBMS determina come recuperarle e restituisce il risultato.
Quando completi un ordine avviene il percorso inverso: l’applicazione invia nuovi dati o modifica quelli esistenti e il DBMS verifica che l’operazione rispetti le regole definite.
Dati, schema e modello: come viene organizzata l’informazione
Prima ancora di scegliere un prodotto come MySQL o MongoDB occorre decidere come rappresentare i dati.
Questo è il ruolo del modello dei dati.
In un database relazionale potremmo separare un e-commerce in tabelle come:
| Tabella | Informazioni principali |
|---|---|
clienti | ID cliente, nome, email |
prodotti | ID prodotto, nome, prezzo |
ordini | ID ordine, cliente, data, stato |
righe_ordine | ordine, prodotto, quantità, prezzo |
Lo schema definisce invece come queste strutture sono organizzate: quali colonne esistono, quali tipi di dato accettano, quali vincoli devono rispettare e come sono collegate.
Un altro modello può rappresentare lo stesso problema in maniera diversa. In un database documentale, per esempio, alcuni dati collegati possono essere memorizzati insieme all’interno di un documento.
Non esiste quindi una struttura universale valida per ogni database.
Query e indici: come vengono recuperati i dati
Una query è una richiesta rivolta al database.
Può servire a:
- recuperare informazioni;
- inserire nuovi dati;
- modificare dati esistenti;
- eliminare informazioni;
- aggregare risultati;
- collegare dati provenienti da strutture differenti.
Nei database relazionali il linguaggio più conosciuto per queste operazioni è SQL, Structured Query Language.
Supponiamo di voler ottenere tutti gli ordini di un cliente. La query non specifica necessariamente dove il DBMS debba andare fisicamente a cercare ciascun byte: esprime soprattutto quale risultato vogliamo ottenere.
Il DBMS sceglie poi un piano di esecuzione.
Qui entrano in gioco anche gli indici. Un indice è una struttura aggiuntiva che consente al database di individuare determinati dati senza dover necessariamente esaminare tutte le righe disponibili.
L’analogia con l’indice di un libro è utile, ma ha un limite importante: gli indici occupano spazio e devono essere mantenuti quando i dati cambiano. Aggiungere più indici non rende automaticamente un database più veloce. Può accelerare alcune letture e allo stesso tempo aumentare il lavoro necessario per scritture e aggiornamenti.
Transazioni e integrità: cosa succede quando i dati cambiano
Molte operazioni reali richiedono più modifiche che devono essere considerate come una sola unità logica.
Prendiamo ancora un ordine online. La procedura potrebbe richiedere di:
- creare l’ordine;
- registrare le righe dell’ordine;
- aggiornare la disponibilità;
- registrare lo stato del pagamento.
Se un errore interrompesse il processo dopo il primo passaggio, potremmo ritrovarci con un ordine incompleto.
Una transazione serve a coordinare operazioni di questo tipo.
Nel mondo relazionale si incontra spesso l’acronimo ACID:
- Atomicity: le operazioni della transazione vengono completate come unità oppure annullate;
- Consistency: la transazione deve rispettare regole e vincoli definiti dal sistema;
- Isolation: transazioni concorrenti vengono gestite secondo regole che limitano interferenze indesiderate;
- Durability: una volta confermata, una modifica deve sopravvivere a guasti secondo le garanzie offerte dal sistema.
Questi concetti spiegano perché i database sono utilizzati per ordini, inventari, prenotazioni e sistemi in cui una modifica parziale potrebbe produrre dati incoerenti.
Database relazionale: come funziona il modello relazionale
Un database relazionale organizza i dati in relazioni normalmente rappresentate come tabelle composte da righe e colonne. Le tabelle possono essere collegate tramite valori e chiavi comuni.
È uno dei modelli più importanti nella storia dei database e continua a essere utilizzato in moltissime applicazioni transazionali e gestionali.
AWS e Oracle descrivono entrambi il modello relazionale attraverso dati organizzati in tabelle e relazioni definite fra le informazioni.
Tabelle, righe, colonne e record
Una tabella rappresenta generalmente una classe di entità omogenee.
Una tabella clienti, per esempio, potrebbe contenere:
| id_cliente | nome | |
|---|---|---|
| 101 | Anna Rossi | [email protected] |
| 102 | Marco Bianchi | [email protected] |
Le colonne descrivono gli attributi disponibili, come nome ed email.
Le righe, spesso chiamate anche record in un contesto pratico, rappresentano le singole occorrenze.
Questa struttura diventa davvero interessante quando smettiamo di mettere tutto in un’unica tabella.
Se inserissimo nella tabella dei clienti anche ogni prodotto acquistato, indirizzo, pagamento e dettaglio dell’ordine, avremmo rapidamente duplicazioni e difficoltà di aggiornamento.
Il modello relazionale consente invece di separare le entità e ricostruire i collegamenti quando servono.
Chiave primaria, chiave esterna e relazioni tra tabelle
Una chiave primaria identifica una riga della tabella.
Nel nostro esempio:
id_cliente = 101
identifica Anna Rossi indipendentemente dal fatto che in futuro cambi email o altre informazioni.
Una chiave esterna può invece collegare una riga di una tabella a una riga di un’altra tabella.
La tabella ordini potrebbe essere:
| id_ordine | id_cliente | data_ordine | stato |
|---|---|---|---|
| 5001 | 101 | 14-05 | pagato |
| 5002 | 102 | 15-05 | in lavorazione |
| 5003 | 101 | 18-05 | spedito |
id_cliente permette di sapere a chi appartiene ciascun ordine senza duplicare nome ed email del cliente in ogni riga.
Da qui nascono relazioni come:
- uno a uno;
- uno a molti;
- molti a molti.
Cliente → ordini è normalmente una relazione uno-a-molti: un cliente può avere molti ordini.
Ordini → prodotti è invece un buon esempio di relazione molti-a-molti. Un ordine può contenere diversi prodotti e un prodotto può comparire in molti ordini. Per rappresentarla viene spesso utilizzata una tabella intermedia, come righe_ordine.
Questo è il punto in cui un database relazionale smette di sembrare una semplice raccolta di fogli: la struttura permette di conservare una volta l’informazione e ricostruire le relazioni quando serve.
SQL e JOIN: come si interrogano dati collegati
SQL permette di interrogare i database relazionali utilizzando istruzioni dichiarative.
Per conoscere gli ordini di Anna potremmo collegare clienti e ordini tramite il campo id_cliente.
SELECT
clienti.nome,
ordini.id_ordine,
ordini.data_ordine,
ordini.stato
FROM clienti
JOIN ordini
ON clienti.id_cliente = ordini.id_cliente
WHERE clienti.id_cliente = 101;
Il JOIN indica al DBMS come mettere in relazione le righe delle due tabelle.
Il risultato potrebbe essere:
| nome | id_ordine | data_ordine | stato |
|---|---|---|---|
| Anna Rossi | 5001 | 14-05 | pagato |
| Anna Rossi | 5003 | 18-05 | spedito |
Non abbiamo copiato il nome di Anna dentro ogni ordine. Lo abbiamo recuperato quando necessario attraverso la relazione.
Questa separazione è fondamentale perché riduce duplicazioni inutili e rende più controllabile la consistenza dei dati.
Transazioni ACID: perché contano nei sistemi reali
Il modello relazionale viene spesso scelto quando il progetto presenta relazioni forti fra le entità e operazioni transazionali che devono mantenere precise garanzie di integrità.
Un trasferimento di denaro è l’esempio classico.
Se 100 euro vengono sottratti dal conto A per essere accreditati al conto B, non vogliamo che il sistema completi soltanto la prima operazione.
Lo stesso principio vale, con conseguenze meno drammatiche, per molti e-commerce:
- creare l’ordine;
- associare i prodotti;
- aggiornare una disponibilità;
- registrare il pagamento.
Questo non significa però che ACID sia esclusiva dei database relazionali. È una distinzione importante: anche sistemi non relazionali possono offrire transazioni con garanzie ACID. MongoDB, per esempio, supporta transazioni multi-documento.
Il confronto corretto fra relazionale e NoSQL deve quindi partire dalle garanzie del sistema specifico e dal workload, non da slogan come “SQL è consistente, NoSQL no”.
Esempio di database relazionale: clienti, ordini e prodotti
Costruiamo ora un esempio completo.
Immagina un piccolo e-commerce con tre concetti centrali:
cliente → ordine → prodotto
Potremmo essere tentati di creare una sola tabella:
| cliente | ordine | prodotto | prezzo | quantità |
|---|
Funzionerebbe per pochi dati, ma produrrebbe subito duplicazioni.
Se Anna effettua dieci ordini, nome ed email potrebbero essere ripetuti dieci volte. Se un ordine contiene cinque prodotti, anche i dati relativi all’ordine verrebbero ripetuti.
Un modello relazionale può separare invece le responsabilità.
Dallo schema alle tabelle
Clienti
| id_cliente | nome | |
|---|---|---|
| 101 | Anna Rossi | [email protected] |
Prodotti
| id_prodotto | nome | prezzo |
|---|---|---|
| 21 | Tastiera | 89 |
| 22 | Mouse | 49 |
Ordini
| id_ordine | id_cliente | stato |
|---|---|---|
| 5001 | 101 | pagato |
Righe ordine
| id_ordine | id_prodotto | quantità | prezzo_unitario |
|---|---|---|---|
| 5001 | 21 | 1 | 89 |
| 5001 | 22 | 2 | 49 |
Il prezzo unitario viene conservato nella riga dell’ordine perché il prezzo del prodotto potrebbe cambiare in futuro. Se domani il mouse costasse 55 euro, l’ordine già effettuato dovrebbe continuare a ricordare il prezzo effettivamente pagato.
È un esempio piccolo, ma mostra un principio importante: progettare un database significa anche stabilire quale informazione appartiene a quale entità e quale stato storico deve essere conservato.
Dalle relazioni alla query: come il database risponde a una domanda
Supponiamo ora che il customer care voglia sapere:
Quali prodotti ha acquistato Anna nell’ordine 5001?
Il DBMS può collegare:
clienti → ordini → righe_ordine → prodotti
e ricostruire il risultato senza conservare tutti i dati nello stesso punto.
Questo esempio spiega anche perché la qualità di un database non dipende esclusivamente dal prodotto scelto. Un modello dei dati sbagliato può creare problemi anche su un DBMS eccellente.
Indici, query, struttura delle relazioni e pattern di accesso fanno parte della progettazione almeno quanto il nome della tecnologia.
Tipi di database: quali modelli esistono
I database possono essere classificati secondo criteri differenti.
Ed è proprio qui che molte guide diventano confuse: mettono nella stessa lista relazionale, cloud, distribuito e vettoriale come se descrivessero necessariamente la stessa dimensione.
Non è così.
Relazionale o documentale descrive soprattutto il modello dei dati. Cloud descrive una modalità di erogazione o deployment. Distribuito descrive un’architettura. Multimodello descrive la capacità di supportare più modelli.
Una stessa piattaforma può quindi appartenere contemporaneamente a più categorie.
IBM include fra le principali famiglie database relazionali, non relazionali, object-oriented, vettoriali e cloud.
Database documentali, key-value, wide-column e a grafo
Con NoSQL si raggruppano diversi approcci che non utilizzano necessariamente il modello relazionale tradizionale.
NoSQL non identifica quindi un unico modello.
Database documentali
Memorizzano dati all’interno di documenti che possono rappresentare insieme informazioni correlate.
MongoDB è uno degli esempi più conosciuti. I documenti MongoDB vengono memorizzati in BSON, un formato binario che estende il modello dei documenti JSON-like.
Questo approccio è utile quando l’applicazione lavora naturalmente con oggetti o documenti e quando la struttura dei dati può evolvere.
“Schema flessibile”, però, non significa assenza di struttura. Anche un database documentale richiede decisioni sul modo in cui dati, documenti e relazioni vengono modellati.
Database key-value
Organizzano l’accesso principalmente attraverso una coppia:
chiave → valore
Sono particolarmente adatti quando l’applicazione conosce la chiave e deve recuperare rapidamente il valore associato.
Redis è un esempio importante, anche se definirlo semplicemente come “database key-value” ne descrive solo una parte delle strutture disponibili.
Se vuoi approfondire questa architettura puoi leggere la nostra guida dedicata a Redis e al suo funzionamento in-memory.
Database wide-column
I database wide-column organizzano i dati per famiglie di colonne e sono progettati per casi d’uso che possono richiedere grandi volumi e distribuzione su più nodi.
Apache Cassandra è uno degli esempi più noti.
La somiglianza terminologica con le colonne dei database relazionali non deve trarre in inganno: il modello e i pattern di accesso sono differenti.
Database a grafo
Un database a grafo rappresenta esplicitamente entità e relazioni attraverso strutture come nodi e archi.
Può essere particolarmente efficace quando il problema centrale consiste nell’attraversare molte relazioni, per esempio:
- social graph;
- sistemi di raccomandazione;
- knowledge graph;
- rilevamento di frodi;
- reti e dipendenze.
Qui la relazione non è semplicemente qualcosa da ricostruire con un JOIN: diventa parte centrale del modello.
Database time-series e database vettoriali
Alcuni database vengono progettati o ottimizzati per tipi di workload più specifici.
Un database time-series gestisce dati fortemente legati al tempo, come metriche, telemetria, misurazioni IoT e serie cronologiche.
Il tempo diventa parte centrale delle operazioni: aggregare finestre temporali, confrontare intervalli o mantenere grandi sequenze di misurazioni.
Un database vettoriale gestisce invece vettori numerici ad alta dimensionalità, spesso ottenuti trasformando contenuti come testo, immagini o audio in embedding.
L’obiettivo tipico non è trovare un valore identico, ma elementi semanticamente o matematicamente simili.
IBM descrive i vector database come sistemi che memorizzano, gestiscono e indicizzano dati vettoriali ad alta dimensionalità per effettuare confronti di similarità.
C’è però una distinzione importante: vector search non implica necessariamente un database esclusivamente vettoriale.
Piattaforme relazionali e general purpose stanno incorporando tipi vettoriali e funzioni di ricerca per similarità. SQL Server, per esempio, supporta nativamente dati vettoriali.
Per questo la domanda utile non è sempre “mi serve un vector database?”, ma:
la ricerca vettoriale è il centro del workload oppure è una capacità che posso integrare nel database già utilizzato dall’applicazione?
Database cloud, distribuiti e multimodello: perché non sono la stessa classificazione
Un database cloud viene eseguito o fornito attraverso infrastrutture cloud. Può essere relazionale, documentale, key-value, vettoriale o di altro tipo.
Un database distribuito conserva o elabora i dati attraverso più nodi. Anche in questo caso il sistema può utilizzare differenti modelli.
Un database multimodello supporta invece più forme di rappresentazione o interrogazione all’interno della stessa piattaforma.
Queste dimensioni oggi si sovrappongono molto più di quanto suggeriscano le vecchie classificazioni rigide.
È possibile avere:
database relazionale + distribuito + cloud + capacità JSON + ricerca vettoriale
nello stesso prodotto.
Per questo è sempre meno utile scegliere una tecnologia esclusivamente in base all’etichetta di categoria.
Database relazionale vs NoSQL: le differenze che contano davvero
La domanda “meglio SQL o NoSQL?” è troppo generica per avere una risposta seria.
La scelta dipende soprattutto da forma dei dati, relazioni, query, garanzie richieste e modalità con cui il sistema deve scalare.
| Criterio | Database relazionale | Database NoSQL |
|---|---|---|
| Modello | Tabelle e relazioni | Dipende dal sistema: documenti, key-value, grafi, wide-column… |
| Schema | Esplicito e controllato; può evolvere | Spesso più flessibile, ma non significa privo di schema |
| Relazioni complesse | Modello naturale, JOIN e vincoli | Dipende dal modello e dal modo in cui vengono rappresentate |
| Linguaggio | SQL nei principali RDBMS | API e linguaggi dipendono dal sistema; alcuni supportano anche SQL-like |
| Transazioni | Forte tradizione transazionale e ACID | Dipende dal prodotto; alcuni offrono transazioni ACID |
| Scalabilità | Verticale e/o orizzontale secondo tecnologia e architettura | Spesso progettata con distribuzione orizzontale come requisito importante |
| Caso tipico | ordini, gestionali, sistemi con relazioni e vincoli | documenti, key-value, grafi o workload specifici |
| Decisione | quando relazioni, integrità e query strutturate sono centrali | quando un modello alternativo rappresenta meglio dati e accessi |
AWS distingue i database relazionali da quelli non relazionali proprio partendo dalla struttura tabellare dei primi e dalla varietà di modelli utilizzata dai secondi.
Schema, relazioni e modello dei dati
Il database relazionale è spesso descritto come “rigido” e NoSQL come “flessibile”.
È una semplificazione.
Un database relazionale usa uno schema esplicito e vincoli strutturali, ma lo schema può essere modificato nel tempo attraverso migrazioni. Molti RDBMS moderni possono inoltre gestire anche dati JSON o altre strutture meno tradizionali.
Un database documentale può permettere documenti con strutture differenti, ma una libertà totale può semplicemente spostare il problema dall’infrastruttura al codice applicativo.
La domanda corretta è quindi:
dove voglio far rispettare la struttura dei dati e quali garanzie deve offrire il database?
Transazioni, consistenza e accesso concorrente
Un altro luogo comune sostiene:
SQL = ACID
NoSQL = eventual consistency
Non è una distinzione affidabile.
Le garanzie cambiano da prodotto a prodotto, configurazione a configurazione e operazione a operazione.
MongoDB, per esempio, supporta transazioni distribuite e multi-documento.
Allo stesso modo, un sistema distribuito può offrire configurazioni diverse per letture, repliche e consistenza.
Quando la coerenza è critica bisogna quindi verificare le garanzie concrete del DBMS scelto, non dedurle dall’etichetta SQL o NoSQL.
Scalabilità e pattern di query
Anche “relazionale = scalabilità verticale” e “NoSQL = scalabilità orizzontale” è ormai troppo semplicistico.
Esistono database relazionali distribuiti, servizi cloud con replica e partizionamento, architetture sharded e piattaforme NoSQL che presentano a loro volta vincoli e trade-off.
La decisione dovrebbe partire dal workload:
- quanto cresce il volume?
- quante letture e scritture sono previste?
- quali query vengono eseguite più spesso?
- quali dati devono essere collegati?
- qual è la latenza accettabile?
- quali garanzie di consistenza servono?
- quali failure devono essere tollerati?
La tecnologia arriva dopo queste domande.
Esempi di DBMS e tecnologie database
Conoscere i nomi dei prodotti è utile, ma una guida generale sui database non dovrebbe trasformarsi in una classifica universale.
I sistemi più conosciuti appartengono infatti a famiglie e casi d’uso differenti.
MySQL
MySQL è un RDBMS sviluppato e mantenuto da Oracle. È molto diffuso nelle applicazioni web e costituisce uno degli esempi più immediati di database relazionale basato su SQL.
Se vuoi approfondire installazione, struttura e query trovi una guida separata su cos’è MySQL e come funziona.
PostgreSQL
PostgreSQL è un sistema di gestione di database relazionali open source con un set molto ampio di funzionalità e possibilità di estensione.
È un buon esempio di quanto la distinzione fra “relazionale” e altri tipi di dati sia oggi meno netta di quanto sembri: un RDBMS moderno può supportare molte capacità aggiuntive senza smettere di utilizzare il modello relazionale come fondamento.
Microsoft SQL Server
SQL Server è la piattaforma database relazionale di Microsoft.
Oltre alle tradizionali funzionalità SQL, le versioni moderne della piattaforma includono capacità per dati vettoriali e similarity search. Questo mostra concretamente perché una funzionalità come il vector search non richiede automaticamente un database completamente separato.
Oracle AI Database
Oracle AI Database è la piattaforma database di Oracle e continua a fondarsi sul modello relazionale integrandolo con ulteriori modelli e capacità.
Anche questo è un esempio della convergenza fra categorie che un tempo venivano presentate come nettamente separate.
MongoDB
MongoDB è un database orientato ai documenti.
I dati vengono memorizzati in documenti BSON e non richiedono lo stesso modello tabellare di un RDBMS.
È particolarmente interessante quando la struttura documentale rappresenta bene l’oggetto utilizzato dall’applicazione, ma la scelta deve comunque considerare query, relazioni, consistenza e modalità di accesso.
Redis
Redis utilizza un approccio in-memory e mette a disposizione strutture dati accessibili attraverso chiavi.
Viene utilizzato in scenari che includono caching, sessioni, dati temporanei e workload a bassa latenza, ma può svolgere anche funzioni più ampie.
Questo è un altro motivo per cui le categorie vanno utilizzate come modelli per capire una tecnologia, non come scatole rigide.
Come scegliere il tipo di database per un progetto
Il modo più affidabile per scegliere un database è evitare di partire dal database.
Parti dal problema.
Non chiederti inizialmente:
Devo usare PostgreSQL o MongoDB?
Chiediti:
Quali dati devo rappresentare e quali operazioni dovrò effettuare su quei dati?
Parti dai dati, dalle relazioni e dalle query che dovrai eseguire
Tre domande sono particolarmente utili.
1. Quali entità esistono?
Clienti, ordini, prodotti, documenti, eventi, dispositivi, messaggi?
2. Quali relazioni esistono fra queste entità?
Un cliente ha molti ordini? Gli utenti sono collegati fra loro? I documenti contengono oggetti annidati? Le relazioni stesse sono l’informazione più importante?
3. Quali domande dovrà porre l’applicazione?
Un buon modello per una query può essere pessimo per un altro pattern di accesso.
Un database non viene progettato soltanto per conservare dati. Viene progettato per il modo in cui quei dati verranno utilizzati.
Valuta transazioni, consistenza, scala e competenze del team
Dopo il modello arrivano i requisiti operativi.
Considera almeno:
- volume dei dati;
- crescita prevista;
- frequenza delle letture;
- frequenza delle scritture;
- accessi simultanei;
- requisiti transazionali;
- consistenza;
- disponibilità;
- backup e disaster recovery;
- latenza;
- distribuzione geografica;
- sicurezza e controllo degli accessi;
- strumenti esistenti;
- esperienza del team;
- costi operativi.
Questa lista spiega perché non esiste un database “migliore” in assoluto.
Una tecnologia teoricamente perfetta per il workload ma sconosciuta a tutto il team può introdurre più rischio di una soluzione leggermente meno elegante ma ben compresa, monitorata e supportata.
Quando una soluzione ibrida o specializzata ha realmente senso
Un’applicazione non deve necessariamente utilizzare un solo database.
Un e-commerce potrebbe avere:
- database relazionale per clienti, ordini e pagamenti;
- Redis per alcune esigenze di cache o dati temporanei;
- motore di ricerca specializzato per la ricerca full-text;
- componente vettoriale per similarity search o retrieval semantico;
- data warehouse separato per analisi.
Questa strategia viene spesso chiamata polyglot persistence: utilizzare tecnologie differenti per esigenze differenti.
Ma comporta un costo.
Più sistemi significano:
- più infrastruttura;
- più monitoraggio;
- più backup;
- più sicurezza da gestire;
- più competenze;
- più punti di failure;
- sincronizzazione più difficile.
Per questo una seconda tecnologia dovrebbe essere introdotta quando risolve un problema reale, non perché è più moderna o interessante.
Database e WordPress: un esempio concreto sul web
Se gestisci siti web, WordPress offre un esempio molto vicino alla pratica quotidiana.
WordPress conserva nel database gran parte delle informazioni dinamiche del sito: post, pagine, utenti, commenti, impostazioni e dati generati da molti plugin.
I requisiti ufficiali di WordPress prevedono MySQL o MariaDB come piattaforme database raccomandate.
Quando apri una pagina WordPress avviene, in forma semplificata, questo processo:
browser → web server/PHP → WordPress → database → WordPress → HTML → browser
Questo aiuta anche a capire perché “database lento” e “sito lento” non siano automaticamente sinonimi.
Il tempo finale dipende dall’intera catena: codice, query, indici, object cache, plugin, hosting, quantità di dati, richieste esterne e altri fattori.
Se vuoi approfondire il lato operativo abbiamo una guida specifica su come ottimizzare il database di WordPress.
Quando invece WordPress non riesce più a comunicare con il server database, può comparire il noto messaggio di errore nella connessione. In quel caso il problema è di troubleshooting e va affrontato separatamente: trovi la procedura nella guida all’errore nello stabilire una connessione al database WordPress.
Se devi intervenire direttamente sulle tabelle, è disponibile anche la guida alla gestione del database WordPress con phpMyAdmin.
Domande frequenti sui database
SQL è un database?
No. SQL è un linguaggio utilizzato per definire, interrogare e modificare dati nei database relazionali.
MySQL, PostgreSQL, SQL Server e Oracle AI Database sono esempi di sistemi di gestione di database che utilizzano SQL.
La distinzione è la stessa che esiste fra una lingua e un’applicazione capace di comprenderla: il linguaggio definisce come esprimere un’operazione, il DBMS è il sistema che la interpreta ed esegue.
Una tabella deve sempre avere una chiave primaria?
Non tutti i DBMS impongono tecnicamente una chiave primaria per ogni tabella, ma avere un identificatore stabile è normalmente una buona decisione nel modello relazionale quando le singole righe rappresentano entità che devono essere identificate e referenziate.
La scelta concreta dipende dal modello.
Il punto importante è non confondere “il software mi permette di creare una tabella senza primary key” con “quella tabella è progettata bene”.
“Database”, “data base” e “base di dati” significano la stessa cosa?
Nel linguaggio informatico italiano database e base di dati indicano sostanzialmente lo stesso concetto.
La grafia inglese standard è database, in una sola parola. “Data base” compare ancora in alcune ricerche e testi, ma è preferibile utilizzare database.
In italiano il termine viene normalmente mantenuto invariato anche al plurale: un database, due database.
Conclusione
Capire un database non significa memorizzare un elenco di prodotti. Significa comprendere come i dati vengono modellati, collegati, interrogati e modificati in modo affidabile.
Il modello relazionale rimane centrale perché tabelle, chiavi, relazioni, SQL e transazioni rappresentano bene moltissimi problemi reali. Ma non è l’unica possibilità: documenti, key-value, grafi, serie temporali e vettori rispondono a esigenze differenti.
La distinzione più utile non è quindi “database tradizionale contro database moderno”.
È questa:
quale modello rappresenta meglio i miei dati, quali query dovrò eseguire e quali garanzie deve rispettare il sistema?
Se rispondi prima a queste domande, scegliere fra un database relazionale, un sistema NoSQL o una combinazione di tecnologie diventa molto più semplice. E soprattutto eviti l’errore più comune: scegliere il prodotto prima di aver capito il problema.