Le 40 migliori domande di colloquio su DBMS nel 2026

Domande intermedie sui colloqui DBMS

Queste domande valutano la tua padronanza tecnica degli strumenti e dei concetti DBMS.

Gli intervistatori usano domande intermedie per capire se sai applicare la conoscenza dei database per risolvere problemi reali. Cercano esperienza pratica con l'ottimizzazione delle query e comprensione di come funzionano i database sotto il cofano.

Spiega i diversi tipi di indici e quando usare ciascuno

• Gli indici clustered riordinano fisicamente i dati della tabella in base ai valori di chiave — puoi averne solo uno per tabella perché i dati possono essere ordinati in un solo modo.
• Gli indici non clustered creano una struttura separata che punta alle righe della tabella senza cambiarne l'ordine fisico. Puoi avere più indici non clustered su una tabella.
• Gli indici composti coprono più colonne e funzionano meglio quando le query filtrano su quelle colonne insieme.
• Gli indici univoci applicano l'unicità offrendo lookup veloci.
• Gli indici parziali indicizzano solo le righe che soddisfano certe condizioni, risparmiando spazio.

Qual è la differenza tra un indice clustered e uno non clustered?

• Gli indici clustered determinano l'ordine fisico di memorizzazione dei dati nella tabella — pensa a un elenco telefonico ordinato per cognome.
• Gli indici non clustered sono come l'indice in fondo a un libro di testo: indicano dove si trovano i dati reali senza cambiare l'ordine delle pagine.

Ecco come creare indici clustered e non clustered:

-- La chiave primaria crea di default un indice clustered
CREATE TABLE employees (
    id INT PRIMARY KEY CLUSTERED,
    name VARCHAR(100),
    email VARCHAR(100)
);

-- Indice separato per ricerche veloci per email
CREATE NONCLUSTERED INDEX idx_email ON employees(email);Offerto da

Una tabella può avere un solo indice clustered ma molti non clustered. Gli indici clustered sono più veloci per le query su intervalli, mentre i non clustered sono migliori per corrispondenze esatte su colonne diverse.

Come ottimizzi una query lenta?

Inizia analizzando il piano di esecuzione per capire dov'è il collo di bottiglia.

EXPLAIN SELECT * FROM orders o 
JOIN customers c ON o.customer_id = c.id 
WHERE o.order_date > '2025-07-01';Offerto da

Ecco tecniche comuni di ottimizzazione:

• Aggiungi indici alle colonne usate nelle clausole WHERE, JOIN e ORDER BY
• Limita i risultati con WHERE prima dei join
• Usa indici covering che includano tutte le colonne necessarie alla query
• R riscrivi le subquery come JOIN quando possibile
• Evita SELECT * — recupera solo le colonne che ti servono

Controlla la presenza di table scan nel piano di esecuzione: spesso sono i peggiori killer di performance.

Cosa sono le transazioni di database e i livelli di isolamento?

Le transazioni di database raggruppano più operazioni in un'unica unità che o riesce completamente o fallisce completamente.

I livelli di isolamento controllano come le transazioni concorrenti vedono le modifiche delle altre:

• READ UNCOMMITTED: può leggere modifiche non confermate (possibili dirty read)
• READ COMMITTED: legge solo dati confermati (default nella maggior parte dei database)
• REPEATABLE READ: la stessa query restituisce gli stessi risultati all'interno di una transazione
• SERIALIZABLE: isolamento più forte, le transazioni girano come se fossero sequenziali

Livelli di isolamento più alti prevengono più problemi, ma riducono concorrenza e prestazioni.

Spiega il concetto di partizionamento del database

Il partizionamento divide tabelle grandi in parti più piccole e gestibili, mantenendole logicamente come un'unica tabella. Ci sono quattro approcci da conoscere.

• Partizionamento orizzontale: divide le righe in base a criteri come intervalli di date:

-- Tabella orders partizionata per anno
CREATE TABLE orders_2023 (...);
CREATE TABLE orders_2024 (...);
CREATE TABLE orders_2025 (...);Offerto da

• Partizionamento verticale: divide le colonne — quelle usate di frequente in una partizione, quelle rare in un'altra.
• Partizionamento tramite hash: distribuisce le righe in base a una funzione di hash.
• Partizionamento per intervallo: usa intervalli di valori come date o ID.

I benefici includono query più veloci (interroghi solo le partizioni rilevanti), manutenzione più semplice e migliore parallelizzazione.

Qual è la differenza tra UNION e UNION ALL?

UNION combina i risultati di più query e rimuove i duplicati, mentre UNION ALL combina i risultati ma mantiene tutte le righe, inclusi i duplicati.

-- UNION rimuove i duplicati (più lenta)
SELECT name FROM employees WHERE department = 'IT'
UNION
SELECT name FROM employees WHERE salary > 50000;

-- UNION ALL mantiene i duplicati (più veloce)
SELECT name FROM employees WHERE department = 'IT'
UNION ALL
SELECT name FROM employees WHERE salary > 50000;Offerto da

Usa UNION ALL quando sai che non ci saranno duplicati o quando i duplicati non sono un problema — è molto più veloce perché salta il passaggio di deduplicazione.

Come gestisci i deadlock in un database?

I deadlock si verificano quando due transazioni aspettano che l'altra rilasci risorse, creando una dipendenza circolare.

La maggior parte dei database rileva automaticamente i deadlock e termina una transazione (la "vittima del deadlock"), consentendo all'altra di proseguire. La transazione terminata viene rollbackata e restituisce un errore.

-- Transazione 1
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
-- attende il lock sul conto 2

-- Transazione 2  
BEGIN;
UPDATE accounts SET balance = balance + 50 WHERE id = 2;
-- prova ad aggiornare il conto 1 -> DEADLOCKOfferto da

Ecco strategie per prevenire i deadlock:

• Accedi alle tabelle nello stesso ordine tra le transazioni
• Mantieni le transazioni brevi
• Usa livelli di isolamento appropriati
• Implementa logiche di retry nell'applicazione

Qual è lo scopo dei vincoli di database?

I vincoli di database fanno rispettare le regole di business e mantengono l'integrità dei dati a livello di database. Ecco cinque tipi di vincoli che ogni professionista deve conoscere:

• Chiave primaria: garantisce l'identificazione univoca
• Chiave esterna: mantiene l'integrità referenziale
• Check: valida che i dati soddisfino condizioni specifiche
• Not null: impedisce valori vuoti
• Unique: assicura l'assenza di duplicati

Ecco come funzionano nella pratica:

CREATE TABLE employees (
    id INT PRIMARY KEY,
    email VARCHAR(100) UNIQUE NOT NULL,
    age INT CHECK (age >= 18 AND age <= 65),
    department_id INT,
    FOREIGN KEY (department_id) REFERENCES departments(id)
);Offerto da

I vincoli impediscono ai dati errati di entrare nel database e intercettano gli errori in anticipo, prima che si diffondano nell'applicazione.

Spiega la replica del database e i suoi tipi

La replica del database copia i dati da un database ad altri per migliorare disponibilità, prestazioni e disaster recovery.

Ci sono quattro tipi di replica da conoscere:

• Master-slave: un master gestisce le scritture, più slave gestiscono le letture. Le modifiche fluiscono dal master agli slave.
• Master-master: più master possono gestire scritture e letture. Più complessa, ma elimina il single point of failure.
• Replica sincrona: attende conferma dalle repliche prima di fare commit (più lenta ma più coerente).
• Replica asincrona: fa commit immediatamente, replica dopo (più veloce ma con potenziale perdita di dati).

Cosa sono i trigger di database e quando usarli?

I trigger sono procedure speciali che si eseguono automaticamente in risposta a eventi di database come INSERT, UPDATE o DELETE.

Ecco un semplice esempio:

CREATE TRIGGER update_modified_date
BEFORE UPDATE ON employees
FOR EACH ROW
BEGIN
    SET NEW.modified_at = NOW();
END;Offerto da

I trigger sono utili per aggiornare automaticamente timestamp, registrare modifiche per audit trail, applicare regole di business complesse o mantenere campi calcolati.

Ma possono rendere difficile il debug, rallentare le operazioni e creare dipendenze nascoste. Usali con parsimonia e documentali bene.

Ora passiamo alle domande avanzate sui colloqui DBMS.

Domande avanzate sui colloqui DBMS

Queste domande testano la tua conoscenza approfondita dell'architettura DBMS e di operazioni complesse sui database.

Gli intervistatori usano domande avanzate per capire se sai progettare e risolvere problemi di sistemi di database su larga scala. Vogliono vedere se comprendi i trade-off tra diversi approcci e se sai prendere decisioni informate sull'architettura dei database.

Spiega lo sharding del database e i relativi trade-off

Lo sharding divide un grande database orizzontalmente su più server, con ogni shard che contiene solo un sottoinsieme dei dati.

Partizioni i dati in base a una chiave di shard, come ID utente, posizione geografica o intervallo di date. Ogni shard opera in modo indipendente, permettendo di scalare oltre i limiti di un singolo server.

-- Esempio: Sharding degli utenti per intervalli di ID
-- Shard 1: user_id 1-1000000
-- Shard 2: user_id 1000001-2000000
-- Shard 3: user_id 2000001-3000000Offerto da

I vantaggi includono scalabilità orizzontale, prestazioni migliori e isolamento dei guasti (un fallimento di uno shard non blocca tutto).

I trade-off includono logica applicativa complessa, assenza di transazioni cross-shard, ribilanciamento difficile e perdita di alcune garanzie ACID tra shard. Le query che attraversano più shard diventano costose.

Cos'è il teorema CAP e come influisce sul design dei database?

Il teorema CAP afferma che i sistemi distribuiti possono garantire solo due delle tre proprietà: coerenza, disponibilità e tolleranza alle partizioni:

• Coerenza: tutti i nodi vedono gli stessi dati nello stesso momento
• Disponibilità: il sistema resta operativo anche quando i nodi falliscono
• Tolleranza alle partizioni: il sistema continua a funzionare nonostante guasti di rete tra nodi

Poiché solo due su tre sono garantite, ecco le combinazioni più comuni:

• Sistemi CA (come gli RDBMS tradizionali) sacrificano la tolleranza alle partizioni — gestiscono male le divisioni di rete
• Sistemi CP (come MongoDB in certe configurazioni) sacrificano la disponibilità — possono rifiutare richieste per mantenere la coerenza
• Sistemi AP (come Cassandra) sacrificano la coerenza — restano disponibili, ma i dati potrebbero essere temporaneamente incoerenti tra i nodi

La maggior parte dei database distribuiti moderni è eventualmente coerente: privilegiano disponibilità e tolleranza alle partizioni, raggiungendo la coerenza nel tempo.

Come progetti uno schema di database per alta concorrenza?

Inizia riducendo la contesa sui lock progettando tabelle che minimizzino i conflitti tra operazioni concorrenti.

Usa il locking ottimistico con colonne di versione invece di lock pessimistici:

-- Aggiungi una colonna versione per il locking ottimistico
CREATE TABLE products (
    id INT PRIMARY KEY,
    name VARCHAR(100),
    price DECIMAL(10,2),
    inventory_count INT,
    version INT DEFAULT 1
);

-- Aggiornamento con controllo della versione
UPDATE products 
SET inventory_count = inventory_count - 1, version = version + 1
WHERE id = 123 AND version = 5;Offerto da

Altri consigli per progettare per alta concorrenza:

• Partiziona le tabelle calde per tempo o altri confini logici
• Usa tabelle separate per pattern di accesso diversi invece di tabelle larghe con usi misti
• Evita indici larghi che creano contesa
• Progetta per carichi prevalentemente in append quando possibile: gli insert causano meno contesa degli update

Spiega MVCC (Multi-Version Concurrency Control)

MVCC consente a più transazioni di accedere agli stessi dati contemporaneamente senza lock, mantenendo più versioni di ogni riga.

Quando avvii una transazione, ottieni uno snapshot del database in quel momento. Altre transazioni possono modificare i dati, ma la tua transazione vede solo la versione esistente all'avvio.

-- La transazione A inizia al tempo T1
BEGIN; -- Vede la versione 1 di tutti i dati

-- La transazione B modifica i dati al tempo T2  
UPDATE accounts SET balance = 1000 WHERE id = 1; -- Crea la versione 2

-- La transazione A vede ancora la versione 1
SELECT balance FROM accounts WHERE id = 1; -- Restituisce il vecchio valore

COMMIT; -- La transazione A fa commit con il suo snapshotOfferto da

I vantaggi includono che i lettori non bloccano gli scrittori, gli scrittori non bloccano i lettori e letture consistenti all'interno delle transazioni.

Gli svantaggi includono overhead di archiviazione per più versioni e processi di pulizia per rimuovere le versioni vecchie.

Cosa sono le viste materializzate e quando usarle?

Le viste materializzate memorizzano fisicamente su disco il risultato di una query, a differenza delle viste normali che eseguono la query a ogni accesso.

Sono perfette per aggregazioni costose che non richiedono dati in tempo reale:

-- Crea una vista materializzata per il riepilogo mensile delle vendite
CREATE MATERIALIZED VIEW monthly_sales AS
SELECT 
    DATE_TRUNC('month', order_date) as month,
    SUM(total_amount) as total_sales,
    COUNT(*) as order_count
FROM orders 
GROUP BY DATE_TRUNC('month', order_date);

-- Aggiorna quando necessario
REFRESH MATERIALIZED VIEW monthly_sales;Offerto da

Sono ideali per query da dashboard, reporting e analisi complesse eseguite ripetutamente su dati stabili.

I trade-off includono spazio aggiuntivo, overhead di manutenzione e dati stantii tra un refresh e l'altro. Funzionano meglio quando puoi tollerare dati leggermente non aggiornati in cambio di performance migliori.

Come gestisci dataset molto grandi che non stanno in memoria?

Progetta per operazioni basate su disco, comprendendo come il database accede ai dati dallo storage.

Usa il partizionamento per assicurarti che le query tocchino solo i segmenti di dati rilevanti:

-- Partiziona per data così le query saltano le partizioni irrilevanti
CREATE TABLE sales_data (
    sale_date DATE,
    amount DECIMAL(10,2),
    customer_id INT
) PARTITION BY RANGE (sale_date);Offerto da

Altri consigli per gestire dataset più grandi della memoria:

• Ottimizza gli indici per le scansioni su intervallo invece che accessi casuali
• Usa storage colonnare per carichi analitici in cui aggreghi colonne specifiche
• Implementa caching dei risultati e paginazione per le query rivolte agli utenti
• Usa repliche di lettura per distribuire il carico di query su più macchine
• Valuta l'archiviazione dei dati: sposta i dati vecchi su storage più economico e mantieni nel database principale solo quelli recenti

Spiega la differenza tra locking pessimistico e ottimistico

Il locking pessimistico presume che i conflitti avverranno e blocca subito le risorse per prevenirli, mentre quello ottimistico presume che i conflitti siano rari e li verifica solo al momento del commit delle modifiche.

-- Pessimistico: blocca subito la riga
BEGIN;
SELECT * FROM accounts WHERE id = 1 FOR UPDATE; -- Blocca la riga
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
COMMIT;

-- Ottimistico: controlla la versione prima di aggiornare
SELECT id, balance, version FROM accounts WHERE id = 1;
-- La logica applicativa avviene qui
UPDATE accounts 
SET balance = balance - 100, version = version + 1 
WHERE id = 1 AND version = 3; -- Fallisce se qualcun altro l'ha aggiornataOfferto da

• Il pessimistico funziona meglio in scenari ad alta contesa, dove i conflitti sono comuni.
• L'ottimistico funziona meglio per carichi con molte letture, dove i conflitti sono rari.

Cos'è la denormalizzazione del database e quando è appropriata?

La denormalizzazione aggiunge intenzionalmente ridondanza a tabelle normalizzate per migliorare le prestazioni delle query.

Replichi i dati tra tabelle per evitare join costosi:

-- Normalizzato: richiede un join per i dettagli dell'ordine
SELECT o.id, c.name, c.email 
FROM orders o 
JOIN customers c ON o.customer_id = c.id;

-- Denormalizzato: informazioni cliente nella tabella degli ordini
SELECT id, customer_name, customer_email 
FROM orders_denormalized;Offerto da

Quando denormalizzare:

• Le prestazioni in lettura sono più importanti delle scritture
• Hai pattern di query prevedibili che beneficiano dell'evitare i join
• Lo storage costa meno del tempo di calcolo
• Puoi gestire la complessità di mantenere sincronizzati i dati denormalizzati

I rischi includono inconsistenza dei dati, costi di storage maggiori e logica di aggiornamento più complessa.

Come progetti per disaster recovery e alta disponibilità?

Inizia progettando la ridondanza a ogni livello — più server di database, percorsi di rete e data center.

Configura la replica con failover automatico:

• Primario: gestisce tutte le scritture
• Replica 1: gestisce le letture nella stessa regione
• Replica 2: gestisce le letture in un'altra regione
• Replica 3: standby per il disaster recovery

Altri consigli:

• Esegui backup regolari con possibilità di ripristino point-in-time
• Testa regolarmente le procedure di failover — un piano di DR che non funziona sotto pressione è inutile
• Usa load balancer per instradare il traffico lontano dai server guasti
• Monitora tutto — devi venire a conoscenza dei problemi prima dei tuoi utenti
• Pianifica diversi scenari di guasto — guasto di un singolo server, outage di un data center, disastri regionali e corruzione dei dati

Spiega il connection pooling del database e perché è importante

Il connection pooling mantiene una cache di connessioni al database che le applicazioni possono riutilizzare invece di crearne di nuove per ogni richiesta.

Creare connessioni è costoso: comporta handshake di rete, autenticazione e allocazione di risorse. I pool eliminano questo overhead.

Ecco un esempio in Python:

# Senza pooling: crea una nuova connessione ogni volta
def get_user(user_id):
    conn = create_connection()  # Costoso!
    result = conn.execute("SELECT * FROM users WHERE id = ?", user_id)
    conn.close()
    return result

# Con pooling: riutilizza connessioni esistenti
pool = ConnectionPool(max_connections=20)
def get_user(user_id):
    conn = pool.get_connection()  # Veloce!
    result = conn.execute("SELECT * FROM users WHERE id = ?", user_id)
    pool.return_connection(conn)
    return resultOfferto da

I benefici includono tempi di risposta più rapidi, carico ridotto sul database, uso controllato delle risorse e migliore gestione dei picchi di traffico.

Dimensiona il pool in base agli utenti concorrenti e alla capacità del database — troppo piccolo causa attese, troppo grande spreca risorse.

Domande comportamentali e basate su scenari DBMS

Queste domande valutano le tue capacità di problem solving e l'esperienza con clienti e team dati.

Gli intervistatori usano domande comportamentali e scenari per capire come gestisci sfide reali sui database. Vogliono comprendere il tuo processo di pensiero, le tue capacità di comunicazione e la tua abilità nel lavorare con persone non tecniche quando emergono problemi di database.

Raccontami di una volta in cui hai dovuto ottimizzare una query lenta. Qual è stato il tuo approccio?

Struttura la tua risposta mostrando un processo di problem solving chiaro.

Inizia descrivendo il problema e il suo impatto: "La nostra dashboard clienti impiegava 45 secondi a caricarsi perché la query principale faceva uno scan completo su una tabella da un milione di righe. Questo frustrava gli utenti e li portava ad abbandonare la pagina."

Illustra l'approccio diagnostico: "Ho analizzato il piano di esecuzione della query e ho scoperto che mancava un indice sulle colonne usate nella clausola WHERE. Ho anche notato che la clausola ORDER BY non era ottimizzata."

Spiega la soluzione e i risultati: "Ho creato un indice composto che copriva sia le colonne di filtro sia quelle di ordinamento. Dopo i test nello staging, l'ho applicato nelle ore di basso traffico. Il tempo della query è sceso da 45 secondi a meno di 2, risolvendo il problema di performance della dashboard."

Sottolinea sempre misurazioni, test e risultati quantificabili nella tua risposta.

Descrivi una situazione in cui hai dovuto spiegare un concetto di database complesso a uno stakeholder non tecnico

Concentrati su come hai reso accessibili concetti tecnici a stakeholder di business.

Scegli un esempio specifico in cui sei riuscito a colmare il divario tecnico. Potresti dire: "Il team marketing era frustrato perché il loro report di segmentazione clienti impiegava 20 minuti per essere eseguito. Invece di spiegare join e indici, ho usato una semplice analogia."

Descrivi il tuo approccio comunicativo: "Ho detto di immaginare di cercare clienti che hanno acquistato sia il prodotto A sia il prodotto B. Il sistema attuale era come cercare manualmente tra ogni ricevuta in un enorme schedario. Dopo l'ottimizzazione, sarebbe stato come avere cartelle organizzate per tipo di prodotto, rendendo la ricerca molto più veloce."

Mostra l'impatto sul business: "Mi sono concentrato su ciò che contava per loro: il report sarebbe passato da 20 a 2 minuti, così potevano ottenere insight più rapidamente e reagire meglio ai cambiamenti di mercato."

Dimostra che sai tradurre il lavoro tecnico in valore di business senza sovraccaricare i non tecnici con dettagli di implementazione.

Come gestiresti una situazione in cui il database è down durante le ore di punta?

Mostra le tue capacità di gestione delle crisi con una risposta strutturata:

• Valutazione immediata: "Per prima cosa determino l'ambito — è un'interruzione completa o alcuni servizi funzionano? Verifico se le repliche di lettura sono ancora accessibili per operazioni critiche in sola lettura."
• Comunicazione con gli stakeholder: "Avviso subito il team di risposta agli incidenti e invio un breve aggiornamento di stato alle unità di business interessate con una stima dei tempi, anche se non ho ancora una soluzione."
• Processo diagnostico: "Controllo log di sistema, spazio su disco, uso della memoria, connettività di rete e log di errori del database per identificare la causa radice. Se è un guasto hardware, avvio il failover al server di standby."
• Aggiornamenti regolari: "Invio aggiornamenti ogni 15–30 minuti per tenere informati gli stakeholder, anche senza progressi. La comunicazione è importante quanto risolvere il problema."
• Revisione post-incidente: "Dopo la risoluzione, documento cosa è successo, perché e cosa faremo per prevenirlo in futuro."

La chiave è dimostrare che sai mantenere la calma sotto pressione mantenendo una comunicazione chiara.

Guidami nella progettazione di uno schema di database per una nuova applicazione e-commerce

Descrivi il tuo approccio passo dopo passo:

• Raccolta requisiti: "Inizio capendo le esigenze di business — cosa si vende, come acquistano i clienti, che tipo di report è necessario e qual è il volume di traffico atteso."
• Identificazione entità: "Identifico le entità core come Utenti, Prodotti, Ordini, OrderItems, Categorie e Pagamenti. Ogni entità rappresenta un concetto chiave da tracciare."
• Progettazione relazioni: "Mappo come queste entità si relazionano. Per esempio, gli Utenti hanno molti Ordini, gli Ordini contengono molti Prodotti tramite OrderItems e i Prodotti appartengono a Categorie."
• Pianificazione performance: "Aggiungo indici su colonne interrogate spesso, come email utente per il login, SKU del prodotto per le ricerche e date degli ordini per i report. Valuto anche il partizionamento di tabelle grandi come Ordini per data."
• Resilienza futura: "Progetto lo schema per accogliere probabili funzionalità future come recensioni, promozioni e tracciamento dell'inventario senza doverlo stravolgere."

Dimostra che pensi sia alle esigenze immediate sia alla scalabilità a lungo termine fin dall'inizio.

Descrivi una volta in cui hai dovuto migrare dati da un sistema di database a un altro. Quali sfide hai affrontato?

Concentrati su pianificazione, esecuzione e problem solving.

Inquadra il contesto: "Siamo passati da MySQL a PostgreSQL per sfruttare un miglior supporto a JSON e funzionalità avanzate di indicizzazione per i nostri carichi analitici."

Elenca problemi e sfide: "La sfida maggiore è stata gestire le differenze nei tipi di dato — il comportamento dei timestamp di MySQL era diverso da quello di PostgreSQL. Avevamo anche stored procedure da riscrivere."

Spiega la soluzione: "Ho creato un piano di migrazione dettagliato con procedure di rollback. Abbiamo eseguito la migrazione a fasi: prima un sottoinsieme di tabelle, poi gradualmente il resto mantenendo la consistenza dei dati."

Chiudi con risultati di test e validazione: "Abbiamo eseguito sistemi in parallelo per due settimane, confrontando i risultati tra vecchio e nuovo database per garantire l'integrità dei dati. Abbiamo anche eseguito test di carico prima del passaggio definitivo."

Come gestisci disaccordi con i colleghi su decisioni di design del database?

Mostra le tue capacità di collaborazione e risoluzione dei conflitti:

• Ascolta e comprendi: "Parto sempre dal capire la loro prospettiva. Spesso i disaccordi nascono da priorità diverse — loro possono privilegiare la comodità degli sviluppatori, io le prestazioni."
• Argomenti basati sui dati: "Supporto le mie raccomandazioni con esempi concreti. Se penso che serva un indice, mostro piani di esecuzione e benchmark di performance."
• Trova un terreno comune: "Di solito concordiamo sull'obiettivo finale — applicazioni veloci e affidabili. Il disaccordo riguarda solo il come arrivarci."

Esempio: "Uno sviluppatore voleva usare un approccio NoSQL per i profili utente, ma io ho proposto un design relazionale. Abbiamo discusso i trade-off, realizzato prototipi di entrambi e scelto la soluzione più adatta ai nostri requisiti di consistenza e all'esperienza del team."

Raccontami di una volta in cui hai lavorato con una scadenza stretta su un progetto di database

Mostra la tua capacità di stabilire priorità e consegnare sotto pressione.

Inquadra la situazione: "Dovevamo consegnare un report critico per un consiglio di amministrazione in tre giorni, ma la query impiegava più di un'ora."

Spiega come hai priorizzato: "Mi sono concentrato sui miglioramenti più impattanti. Invece di ottimizzare tutto, ho individuato le due operazioni più costose nel piano di esecuzione."

Cita quick win: "Ho aggiunto un indice covering per la query principale e partizionato la tabella più grande per data. Il runtime è sceso da 60 a 8 minuti."

Chiudi con comunicazione e risultati: "Ho aggiornato il product manager ogni poche ore per gestire le aspettative del board se necessario. Abbiamo consegnato il report ottimizzato con due giorni di anticipo, diventando un modello per report simili."

Come affronteresti il troubleshooting di un problema di performance del database che si verifica solo sporadicamente?

Mostra il tuo approccio sistematico al debug di problemi intermittenti:

• Stabilisci il monitoring: "Imposterei monitoraggio per catturare metriche quando il problema si verifica — tempi di esecuzione delle query, risorse di sistema, connessioni concorrenti."
• Raccogli dati: "Abiliterei il log delle query per vedere cosa gira quando le prestazioni degradano. Cercherei anche pattern — succede a orari specifici, con certi utenti o durante operazioni particolari?"
• Formula ipotesi: "In base ai dati, formulerei ipotesi. Magari c'è un job batch ogni ora o un report particolare che blocca le tabelle."
• Isolamento e test: "Proverei a riprodurre il problema in un ambiente di test con volumi di dati e pattern di query simili."

Esempio: "Ho rintracciato un problema che si verificava solo il martedì mattina. Si è scoperto che un job di sincronizzazione settimanale girava nello stesso momento del picco di attività, causando contesa sui lock."

Descrivi come gestiresti una richiesta di accesso al database da parte di qualcuno che di solito non lavora con i database

Mostra consapevolezza della sicurezza e capacità di insegnamento.

Valuta le necessità: "Per prima cosa capisco cosa vogliono ottenere. Spesso c'è un modo migliore per ottenere le informazioni senza accesso diretto al database."

Offri alternative evidenziando la sicurezza: "Invece dell'accesso al database, potrei creare una vista in sola lettura, costruire una dashboard o esportare i dati in un file CSV."

Se l'accesso è necessario, la sicurezza resta prioritaria: "Creerei un account in sola lettura con accesso limitato alle sole tabelle necessarie. Fornirei anche una formazione base sulle best practice SQL e su quali query possono impattare le performance."

Stabilisci aspettative: "Spiegherei perché è importante non eseguire query costose nelle ore di punta e chiederei di confrontarsi con me prima di lanciare qualcosa di complesso."

Guidami su come indagheresti segnalazioni di inconsistenza dei dati in un database di produzione

Mostra il tuo approccio sistematico ai problemi di integrità dei dati:

• Valutazione iniziale: "Per prima cosa raccolgo esempi specifici dell'inconsistenza. Quali dati sono errati, quando è stato scoperto e cosa dovrebbero essere?"
• Ricostruzione della timeline: "Controllo log del database, log applicativi e deployment recenti per capire quando potrebbe essere stata introdotta l'inconsistenza."
• Valutazione della portata: "Eseguo query per determinare quanto è diffuso il problema. Colpisce tutti i record o solo alcuni? Ci sono pattern per tempo, azioni utente o sorgenti dati?"
• Analisi della causa radice: "Cerco cause potenziali — bug applicativi, transazioni fallite, problemi di importazione, accessi concorrenti."
• Contenimento immediato: "Se il problema è in corso, identifico e fermo il processo che lo causa. Per i dati storici, determino se e come correggerli in sicurezza."

Esempio: "Ho trovato ordini clienti con quantità negative. Verificando i log applicativi, ho scoperto una race condition nel processo di aggiornamento dell'inventario. Abbiamo corretto il bug applicativo e sistemato gli ordini interessati usando i log delle transazioni."

Consigli per prepararti a un colloquio DBMS

Il modo migliore per superare un colloquio su DBMS è esercitarti con database reali, non solo memorizzare teoria. Gli intervistatori vogliono vedere che sai risolvere problemi concreti, non solo recitare definizioni.

Esercitati con SQL su dataset reali

Non limitarti a semplici SELECT — lavora con dati disordinati e reali.

Scarica dataset da Kaggle o usa database pubblici come il database di esempio Sakila per MySQL. Esercitati con query complesse che coinvolgono più join, sottoquery e aggregazioni. L'obiettivo è sentirti a tuo agio con scenari che incontrerai davvero al lavoro.

Query come questa devono sembrarti facili, e non devi avere problemi a spiegarne ogni parte:

SELECT 
    c.customer_id,
    c.first_name,
    c.last_name,
    COUNT(r.rental_id) as total_rentals,
    SUM(p.amount) as total_spent
FROM customer c
LEFT JOIN rental r ON c.customer_id = r.customer_id
LEFT JOIN payment p ON r.rental_id = p.rental_id
WHERE r.rental_date >= '2025-07-01'
GROUP BY c.customer_id, c.first_name, c.last_name
HAVING COUNT(r.rental_id) > 10
ORDER BY total_spent DESC;Offerto da

Configura il tuo ambiente database

Installa un sistema di database in locale e impara come funziona davvero.

Scegli uno dei sistemi principali — PostgreSQL, MySQL o SQL Server — e configura un'istanza locale. Crea tabelle, inserisci dati ed esplora diverse configurazioni. Impara a leggere i piani di esecuzione, creare indici e monitorare le prestazioni.

Questa esperienza pratica ti aiuterà a rispondere a domande sull'amministrazione di database, non solo sulla sintassi SQL.

>Se stai facendo colloqui per un ruolo di Database Admin, devi saper rispondere a queste top 30 domande da DBA

Studia problemi reali di performance

Impara a identificare e risolvere i colli di bottiglia più comuni.

Usa strumenti come EXPLAIN o EXPLAIN ANALYZE per capire come vengono eseguite le tue query:

EXPLAIN ANALYZE 
SELECT * FROM orders 
WHERE customer_id = 12345 
AND order_date > '2023-01-01';Offerto da

Esercitati a identificare table scan, indici mancanti e join inefficienti. Crea dataset grandi e osserva come le diverse strategie impattano le prestazioni.

Capire i piani di esecuzione è ciò che distingue i junior dai senior nei colloqui.

Esercitati nel design del database

Lavora su esercizi completi di progettazione di schema, non solo su singole tabelle.

Scegli scenari reali come un sito e-commerce, una piattaforma social o un sistema di inventario. Progetta l'intero schema, incluse relazioni, vincoli e indici. Pensa a come il design gestirà crescita e requisiti in evoluzione.

Disegna diagrammi entità-relazione e preparati a spiegare le tue scelte. Spesso gli intervistatori chiedono "perché hai scelto questo approccio rispetto alle alternative?" Assicurati di avere una risposta.

>Ti consiglio di dare un'occhiata al corso Database Design per portare le tue conoscenze al livello successivo. 

Rivedi concetti SQL e NoSQL

Anche se il ruolo è focalizzato sui relazionali, capisci quando ha senso NoSQL.

Conosci le basi dei document store come MongoDB, dei key-value store come Redis e dei database a famiglie di colonne come Cassandra. Comprendi i trade-off tra coerenza e disponibilità nei sistemi distribuiti.

Dimostra che sai andare oltre una sola tecnologia e scegliere lo strumento giusto per il problema.

>Il corso NOSQL Concepts è un ottimo punto di partenza.

Prepara storie su problemi reali di database

Pensa a esempi specifici in cui hai risolto sfide sui database.

Prepara 3–4 storie su quando hai ottimizzato query lente, progettato schemi, migrato dati o gestito outage del database. Usa il metodo STAR — Situazione, Compito, Azione, Risultato — per strutturare le risposte.

Esercitati a spiegare concetti tecnici a pubblici non tecnici. Spesso chiedono come comunicheresti problemi di database agli stakeholder di business.

Rimani aggiornato sulle tendenze dei database

Leggi le tecnologie e pratiche moderne per i database.

Segui blog, partecipa a webinar o unisciti a community. Conosci argomenti come sharding, MVCC, database distribuiti e servizi database in cloud.

Non devi essere esperto in tutto, ma mostrare consapevolezza delle tendenze indica che resti coinvolto nel campo.

Ricapitolando le domande di colloquio DBMS

I colloqui su DBMS testano tutto, dalla sintassi SQL di base alle decisioni complesse di progettazione dei sistemi.

Per superarli, padroneggia i concetti fondamentali come normalizzazione, indicizzazione e transazioni. Poi affronta argomenti avanzati come sharding e progettazione ad alta disponibilità. La teoria da sola non basta — devi collegare le conoscenze sui database a problemi reali di business.

I migliori candidati collegano i concetti tecnici a risultati pratici. Quando spieghi gli indici, menziona come riducono i tempi da minuti a secondi. Quando parli di replica, spiega come previene downtime costosi.

Esercitati a spiegare chiaramente concetti complessi a stakeholder non tecnici. Prepara storie specifiche su ottimizzazione delle performance, gestione di outage o design di schema con risultati misurabili — "ridotto il tempo delle query del 90%" batte "rese le query più veloci".

>Accanto a SQL e DBMS, non guasta prepararsi anche alle domande di colloquio sul Data Warehouse

Padroneggia le basi, esercitati con dati reali e collega sempre le tue conoscenze tecniche al valore per il business: così si ha successo nei colloqui DBMS. La pratica rende perfetti.

Per imparare le competenze fondamentali su database e design dei database, consiglio questi corsi e materiali di DataCamp:

• Introduction to Relational Databases in SQL
• Introduction to Oracle SQL
• SQL Server for Database Administrators
• Introduction to dbt