Odpowiedź.

Tabele logów zmian (log/audit tables) to zwykłe tabele, w które zapisywane są zdarzenia zmiany danych w produkcyjnych tabela: kto, kiedy i co zmienił. Ważne dla sektora finansowego, e-commerce, instytucji rządowych.

Podejścia do realizacji:

1. Jawne zapisanie w logu przez aplikację lub procedurę.
2. Użycie triggerów do monitorowania wszelkich zmian.
3. W nowych DBMS — systemowe mechanizmy Change Data Capture (CDC) lub Temporal Tables.

Typowy skład:

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

Przykład kodu (trigger do audytu 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

Pułapki:

• Duża objętość tabeli audytowej może spowolnić zapytania.
• Niezbędne jest sensowne partycjonowanie/usuwanie starych danych.
• Należy śledzić blokady i deduplikację zmian.

Pytanie z podstępem.

P: Czy zapis w tabeli logu jest automatycznie cofany przy rollbacku głównej transakcji?

O: Jeśli trigger jest częścią transakcji, to tak, wstawka do logu jest wycofywana razem z główną operacją. Jednak przy logowaniu na poziomie aplikacji/osobnej transakcji może nie być spójności.

Przykłady rzeczywistych błędów z powodu braku znajomości zawirowań tematu.

---

Historia

W instytucji kredytowej mechanizm czyszczenia tabeli audytowej nie został wdrożony. Objętość przekroczyła setki milionów wierszy, co doprowadziło do długich backupów, braku miejsca i degradacji wydajności całej bazy danych.

---

Historia

Programista prowadził audyt przez oddzielne połączenie poza transakcją. W wyniku tego pojawiały się zapisy o zdarzeniach, które nie istniały (transakcja logiki aplikacyjnej była wycofywana, a zapis w logu — nie).

---

Historia

Przy projektowaniu logu zmian wprowadzono wszystkim polom typ NVARCHAR(MAX) dla uniwersalności. Było to niepotrzebne, a jedynie przeciążało przechowywanie i indeksowanie — dane nie mogły być skutecznie analizowane.