Risposta.

Le tabelle di log delle modifiche (log/audit tables) sono tabelle normali in cui vengono registrati gli eventi di modifica dei dati nelle tabelle di produzione: chi, quando e cosa è stato cambiato. Questo è rilevante per il settore finanziario, e-commerce, enti pubblici.

Approcci all'implementazione:

1. Registrazione esplicita nel log tramite applicazione o procedura.
2. Utilizzo di trigger per monitorare tutte le modifiche.
3. In nuovi DBMS — meccanismi di Change Data Capture (CDC) o Temporal Tables.

Composizione tipica:

• audit_id (PK), TableName, OperationType (I/U/D), RecordID, OldValue, NewValue, ChangedBy, ChangeDT

Esempio di codice (trigger per audit UPDATE)

CREATE TABLE ProductAudit (
  AuditID int IDENTITY(1,1) PRIMARY KEY,
  ProductID int,
  OldPrice money,
  NewPrice money,
  ChangedBy sysname,
  ChangeDT datetime,
  OperationType char(1)
);
GO
CREATE TRIGGER trg_ProductAudit
ON Products
AFTER UPDATE
AS
BEGIN
  INSERT INTO ProductAudit(ProductID, OldPrice, NewPrice, ChangedBy, ChangeDT, OperationType)
    SELECT d.ProductID, d.Price, i.Price, SYSTEM_USER, GETDATE(), 'U'
    FROM inserted i JOIN deleted d ON i.ProductID = d.ProductID
    WHERE i.Price <> d.Price;
END

Insidie:

• L'alto volume della tabella di audit può rallentare le query.
• Necessità di una corretta partizionamento/rimozione dei dati obsoleti.
• È importante monitorare i lock e la deduplicazione delle modifiche.

Domanda trabocchetto.

D: La registrazione nel log viene annullata automaticamente se viene ripristinata la transazione principale?

A: Se il trigger è parte della transazione, allora sì, l'inserimento nel log viene annullato insieme all'operazione principale. Tuttavia, con il logging a livello di applicazione/una transazione separata, la coerenza potrebbe non essere garantita.

Esempi di errori reali a causa della mancanza di conoscenza delle sottigliezze dell'argomento.

---

Storia

In un ente di credito non è stato implementato un meccanismo di pulizia della tabella di audit. Il volume ha superato centinaia di milioni di righe, portando a backup lunghi, mancanza di spazio e degrado delle prestazioni dell'intero DB.

---

Storia

Un sviluppatore ha eseguito l'audit tramite una connessione separata al di fuori della transazione. Di conseguenza, sono apparse registrazioni di eventi che non esistevano (la transazione della logica applicativa è stata annullata, mentre la registrazione nel log no).

---

Storia

Durante la progettazione del log delle modifiche, è stato impostato a tutte le colonne il tipo NVARCHAR(MAX) per universalità. Questo non era necessario, ma ha sovraccaricato lo storage e l'indicizzazione, rendendo impossibile analizzare i dati in modo efficace.