La scelta del tipo di database è una delle decisioni architetturali più importanti quando si progetta una soluzione dati su Azure. La distinzione fondamentale è tra database relazionali e database non relazionali (spesso chiamati NoSQL): non esiste un vincitore assoluto, ma solo il modello più adatto alla struttura dei dati, alle esigenze di scalabilità e al tipo di query previste.

Database relazionali

Un database relazionale organizza i dati in tabelle composte da righe (record) e colonne (attributi). Ogni riga rappresenta un’entità e ogni colonna un campo con un tipo di dato definito.

Le caratteristiche distintive sono:

  • Schema fisso (schema-on-write): la struttura delle tabelle va definita prima di inserire i dati. Ogni riga deve rispettare lo schema.
  • Integrità referenziale: le relazioni tra tabelle sono garantite da chiavi primarie e chiavi esterne (foreign key), che impediscono dati orfani o incoerenti.
  • Linguaggio SQL per interrogare e manipolare i dati, con operazioni di JOIN tra più tabelle.
  • Transazioni ACID (Atomicity, Consistency, Isolation, Durability), che garantiscono coerenza forte dei dati.

Su Azure i principali servizi relazionali sono Azure SQL Database, Azure SQL Managed Instance, Azure Database for PostgreSQL e Azure Database for MySQL.

Il modello relazionale è ideale quando i dati sono altamente strutturati e stabili, le relazioni tra entità sono importanti e servono transazioni affidabili: gestionali, contabilità, ordini, sistemi di prenotazione.

Database non relazionali (NoSQL)

I database non relazionali abbandonano lo schema rigido a favore della flessibilità. Adottano tipicamente uno schema-on-read: la struttura viene interpretata al momento della lettura, quindi record diversi possono avere campi diversi. Scalano meglio in orizzontale (scale-out) distribuendo i dati su più nodi.

Esistono quattro famiglie principali:

Chiave-valore (key-value)

Ogni elemento è una coppia chiave → valore. Semplicissimo e velocissimo per accessi diretti tramite chiave. Ideale per cache, sessioni utente e profili. Esempio: Azure Cosmos DB for Table, Azure Cache for Redis.

Documento (document)

I dati sono salvati come documenti JSON autoconsistenti. Ogni documento può avere una struttura diversa, perfetto per dati semi-strutturati come cataloghi prodotti o profili. Esempio: Azure Cosmos DB for NoSQL e for MongoDB.

Colonnare (column-family / wide-column)

I dati sono organizzati per famiglie di colonne, ottimizzate per letture massive su enormi volumi. Adatto a dati IoT, telemetria e serie temporali. Esempio: Azure Cosmos DB for Apache Cassandra.

Grafo (graph)

Rappresenta i dati come nodi (entità) e archi (relazioni). Eccellente quando le relazioni stesse sono il dato più importante: social network, motori di raccomandazione, rilevamento frodi. Esempio: Azure Cosmos DB for Apache Gremlin.

Quando usare cosa

Alcuni criteri guida per orientarsi:

  • Struttura dei dati: dati regolari e tabellari → relazionale; dati eterogenei, annidati o con schema variabile → documento/NoSQL.
  • Relazioni e integrità: se servono JOIN complessi e vincoli referenziali forti → relazionale; se conta esplorare connessioni tra entità → grafo.
  • Scalabilità: scalabilità estrema in orizzontale e distribuzione globale → NoSQL, in particolare Azure Cosmos DB (scalabilità globale con SLA di latenza).
  • Tipo di query: query analitiche SQL con aggregazioni → relazionale; accessi rapidissimi per chiave → key-value; letture su miliardi di righe → colonnare.
  • Coerenza vs velocità: transazioni ACID → relazionale; alta velocità e disponibilità con coerenza più flessibile → NoSQL.

Trappole tipiche d’esame

  • Scenario: dati con struttura che cambia frequentemente e campi diversi per ogni record → la risposta giusta è un database documento (Azure Cosmos DB for NoSQL), non un database relazionale con schema fisso.
  • Scenario: serve rappresentare relazioni complesse tra persone (chi conosce chi, raccomandazioni) → scegli un database a grafo (Gremlin), non uno relazionale con molte foreign key.
  • Scenario: occorre memorizzare sessioni utente o dati di cache con accesso rapidissimo per chiave → key-value / Azure Cache for Redis, non un database SQL.
  • Scenario: applicazione che richiede transazioni ACID e integrità referenziale (es. gestione ordini contabili) → Azure SQL Database (relazionale), non NoSQL.
  • Scenario: serve scalabilità globale con bassa latenza garantita e distribuzione multi-regione → Azure Cosmos DB, l’unico presentato come database NoSQL globalmente distribuito.