From b12eab7aa6dcc1b431d39905fcb6a6e03b347db3 Mon Sep 17 00:00:00 2001 From: allebonvi Date: Tue, 30 Jun 2026 17:03:08 +0200 Subject: [PATCH] Definisci convenzione audit sulle tabelle --- docs/specs/03_modello_concettuale.md | 26 ++++++++++++++++++++++++ docs/specs/07_entita_configurabili.md | 29 +++++++++++++++++++++++++++ 2 files changed, 55 insertions(+) diff --git a/docs/specs/03_modello_concettuale.md b/docs/specs/03_modello_concettuale.md index c73c1b6..184b2d7 100644 --- a/docs/specs/03_modello_concettuale.md +++ b/docs/specs/03_modello_concettuale.md @@ -4,6 +4,32 @@ Il modello deve essere abbastanza generale da non ripetere i limiti del legacy, ## Entita' principali +## Convenzione audit comune + +Tutte le tabelle persistenti di dominio devono avere un blocco audit standard. + +Campi minimi: + +- created_by; +- created_at; +- updated_by; +- updated_at; +- deleted_by; +- deleted_at. + +Questa forma e' volutamente esplicita per rendere semplice interrogare il database anche senza passare dall'applicazione. + +Le cancellazioni fisiche devono essere evitate nelle tabelle operative. La regola di default e' il soft delete: + +```text +deleted_at valorizzato = record cancellato logicamente +deleted_at nullo = record attivo +``` + +Per tabelle molto semplici o di sistema si puo' valutare una convenzione piu' compatta, ma il default del progetto resta il blocco audit esplicito. + +Quando serve ricostruire la sequenza completa degli eventi, il blocco audit della riga non basta. In questi casi si usa anche AuditEvent, che registra azione, utente, timestamp, origine, valori prima/dopo e riferimento alla transazione. + ### LogisticUnit Rappresenta una qualsiasi unita' fisica movimentabile. diff --git a/docs/specs/07_entita_configurabili.md b/docs/specs/07_entita_configurabili.md index 354d88e..eec475e 100644 --- a/docs/specs/07_entita_configurabili.md +++ b/docs/specs/07_entita_configurabili.md @@ -229,6 +229,35 @@ Ogni azione che cambia stock, stato o configurazione deve registrare: Questo e' indispensabile per produzione, assistenza e consulenza. +### Campi audit standard su tutte le tabelle + +Tutte le tabelle persistenti di dominio devono adottare un blocco audit comune. + +Forma consigliata: + +- created_by; +- created_at; +- updated_by; +- updated_at; +- deleted_by; +- deleted_at. + +Questa forma e' piu' leggibile di soluzioni troppo sintetiche come un singolo campo JSON di audit. + +Il vantaggio e' che ogni tabella resta interrogabile direttamente con SQL semplice, anche durante assistenza, debug o migrazione. + +Le cancellazioni devono essere logiche, non fisiche, salvo casi tecnici molto controllati. + +Un record con deleted_at valorizzato e' considerato cancellato. + +Un record con deleted_at nullo e' considerato attivo. + +Questo blocco audit non sostituisce AuditEvent. + +Il blocco audit serve a sapere lo stato amministrativo corrente della riga. + +AuditEvent serve invece a ricostruire la sequenza storica completa delle operazioni. + ## Entita' teoriche di supporto Oltre alle entita' operative elencate sotto, il modello dovra' prevedere almeno queste entita' di supporto, anche se alcune possono essere minime nell'MVP: