Domain Knowledge Base - Databases & SQL
Come funziona il dominio, prima di scrivere una riga di codice? Scegli un documento dall'albero a sinistra: ogni pagina spiega una parte del modello.
Regole di Business - Databases & SQL
Questo documento elenca le regole di business fondamentali del dominio Databases & SQL, identificate con codice univoco BR-NNN. Ogni regola è technology-independent e descrive un vincolo invariante sul comportamento di un sistema di gestione di basi di dati relazionali.
---
BR-001 - Atomicità delle transazioni
Codice: BR-001
Nome: Ogni Transazione è atomica: tutto-o-niente
Descrizione: Un insieme di operazioni racchiuse in una Transazione deve essere applicato interamente o per niente. Se una qualsiasi operazione fallisce, l'intera transazione viene annullata (rollback) e il database torna allo stato precedente al BEGIN. Non sono ammessi stati parziali visibili.
Motivazione: Garantire la proprietà di atomicità (la "A" di ACID) e l'integrità dei dati in presenza di guasti.
Priorità: CRITICA
Attori: Backend Developer, DBMS
Violazione: stato inconsistente con scritture parziali → rollback forzato.
Tracciabilità: glossary ACID, Transazione, Savepoint, Write-Ahead Log; SQL:2016 §4.35.
---
BR-002 - Integrità referenziale applicata dai vincoli
Codice: BR-002
Nome: Le chiavi esterne devono riferirsi a righe esistenti
Descrizione: Una colonna definita come FOREIGN KEY non può contenere un valore che non esiste nella tabella referenziata (salvo NULL se ammesso). Le operazioni di DELETE/UPDATE sulla riga referenziata seguono la policy dichiarata (RESTRICT, CASCADE, SET NULL). I vincoli sono applicati dal DBMS, non dall'applicazione.
Motivazione: Garantire la coerenza relazionale e prevenire righe orfane.
Priorità: ALTA
Attori: DBA, Backend Developer
Violazione: evento ConstraintViolato; l'operazione è rifiutata con errore di integrità.
Tracciabilità: glossary Integrità referenziale, Chiave esterna, Vincolo; SQL:2016 §11.8.
---
BR-003 - Le migrazioni di schema sono versionate e ordinate
Codice: BR-003
Nome: Ogni MigrazioneDB ha una versione univoca e si applica in ordine deterministico
Descrizione: Le modifiche allo Schema avvengono solo tramite MigrazioneDB versionate, applicate in sequenza monotòna. Una migrazione già applicata non viene rieseguita; una nuova migrazione si applica solo dopo tutte le precedenti. Lo stato delle migrazioni è registrato in una tabella di controllo.
Motivazione: Rendere l'evoluzione dello schema riproducibile, tracciabile e identica tra ambienti (dev/staging/prod).
Priorità: ALTA
Attori: DBA, Migration Tool, Backend Developer
Violazione: ordine non deterministico → schema divergente tra ambienti.
Tracciabilità: glossary DDL, Schema; state-machine migration-lifecycle.md; evento MigrazioneEseguita.
---
BR-004 - Le query applicative usano prepared statement
Codice: BR-004
Nome: Ogni query con input variabile deve usare parametri bindati, mai concatenazione di stringhe
Descrizione: Le query che includono valori provenienti dall'esterno devono essere costruite con prepared statement e parametri bindati (?/$1/:name), così che i valori non siano mai interpretati come SQL. La concatenazione di input nelle stringhe SQL è vietata.
Motivazione: Prevenire la SQL injection e abilitare il riuso del piano di esecuzione.
Priorità: CRITICA
Attori: Backend Developer
Violazione: vulnerabilità di SQL injection; codice rifiutato in review.
Tracciabilità: glossary Prepared statement, SQL injection; OWASP A03:2021.
---
BR-005 - Gli indici servono i pattern di accesso, non ogni colonna
Codice: BR-005
Nome: Un Indice si crea per supportare query reali, bilanciando lettura e scrittura
Descrizione: Gli indici accelerano le letture selettive ma rallentano le scritture e occupano spazio. Un Indice va creato quando una query frequente filtra/ordina/unisce su una colonna selettiva, e va rimosso se inutilizzato. Gli indici compositi seguono l'ordine left-prefix dei predicati più selettivi.
Motivazione: Ottimizzare le prestazioni di lettura senza penalizzare eccessivamente le scritture.
Priorità: MEDIA
Attori: DBA, Query Optimizer, Backend Developer
Violazione: over-indexing (scritture lente) o full table scan ricorrenti (letture lente).
Tracciabilità: glossary Indice, Indice composito, Indice B-tree; evento IndiceCreato; QueryPlan.
---
BR-006 - Il livello di isolamento è scelto consapevolmente
Codice: BR-006
Nome: Ogni Transazione opera a un livello di isolamento esplicito e adeguato
Descrizione: Il livello di isolamento (READ COMMITTED, REPEATABLE READ, SERIALIZABLE, ecc.) determina quali anomalie di concorrenza (dirty read, non-repeatable read, phantom) sono possibili. La scelta deve bilanciare correttezza e contesa; livelli più alti riducono le anomalie ma aumentano lock/abort.
Motivazione: Garantire la correttezza in concorrenza senza degradare inutilmente la concorrenza stessa.
Priorità: ALTA
Attori: Backend Developer, DBA
Violazione: anomalie di concorrenza non gestite (dati incoerenti) o contesa eccessiva.
Tracciabilità: glossary Livello di isolamento, MVCC; SQL:2016 §4.35.4.
---
BR-007 - Backup verificati e ripristinabili
Codice: BR-007
Nome: Esiste sempre un backup recente e testato per il ripristino
Descrizione: Il database deve avere backup periodici (full + incrementali/WAL) la cui ripristinabilità è verificata con test di restore. La frequenza dei backup e la retention rispettano gli obiettivi di RPO/RTO dichiarati. Un backup non testato non è considerato valido.
Motivazione: Garantire la recuperabilità in caso di guasto, corruzione o errore umano.
Priorità: CRITICA
Attori: DBA
Violazione: perdita di dati irreversibile in caso di disastro.
Tracciabilità: glossary Write-Ahead Log, Replica; evento BackupCompletato.
---
BR-008 - Il connection pool è limitato e monitorato
Codice: BR-008
Nome: Le connessioni al database sono gestite tramite un pool con limite massimo
Descrizione: Le applicazioni accedono al database tramite un connection pool con un numero massimo di connessioni dimensionato sulle risorse del server. Le connessioni inattive vengono riciclate; quelle che eccedono il pool attendono o falliscono con un timeout esplicito, mai aprendo connessioni illimitate.
Motivazione: Prevenire l'esaurimento delle risorse del DBMS e degradi a cascata.
Priorità: ALTA
Attori: Backend Developer, DBA
Violazione: evento ConnectionPoolEsaurito; nuove richieste in errore o in attesa indefinita.
Tracciabilità: glossary Connection pool; evento ConnectionPoolEsaurito.