Salta al contenuto principale

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.