Antwoord.

Logtabellen voor wijzigingen (log/audit tables) zijn gewone tabellen waarin de gebeurtenissen van gegevenswijzigingen in productietabellen worden opgeslagen: wie, wanneer en wat er is veranderd. Relevant voor de financiële sector, e-commerce, overheidsinstellingen.

Aanpak voor implementatie:

1. Expliciete registratie in het log via de applicatie of procedure.
2. Gebruik van triggers om wijzigingen bij te houden.
3. In nieuwe DBMS-systemen — systeemmechanismen voor Change Data Capture (CDC) of Temporal Tables.

Typische samenstelling:

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

Voorbeeldcode (trigger voor 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

Valkuilen:

• Een grote audit-tabel kan de query-prestaties vertragen.
• Er is een goede partitionering/het verwijderen van oude gegevens nodig.
• Je moet letten op blokkeringen en deduplicatie van wijzigingen.

Catchphrase vraag.

Q: Wordt een ingevoegde record in de logtabel automatisch teruggedraaid bij het terugdraaien van de hoofdbewerking?

A: Als de trigger deel uitmaakt van de transactie, dan is het ja, de invoer in het log wordt teruggedraaid samen met de hoofdoperatie. Echter, bij loggen op applicatieniveau/een aparte transactie kan er geen consistentie zijn.

Voorbeelden van echte fouten door gebrek aan kennis over de nuances van het onderwerp.

---

Verhaal

In een kredietinstelling was er geen mechanismen voor het opschonen van de audit-tabel geïmplementeerd. De omvang oversteeg honderd miljoen rijen, wat leidde tot lange back-ups, gebrek aan ruimte en degradatie van de prestaties van de hele database.

---

Verhaal

De ontwikkelaar deed audit via een aparte verbinding buiten de transactie. Hierdoor verschenen er records van gebeurtenissen die niet bestonden (de applicatielogica transactie werd teruggedraaid, maar de invoer in de log niet).

---

Verhaal

Bij het ontwerpen van het logboek voor wijzigingen werden alle velden het type NVARCHAR(MAX) gegeven voor universele toepasbaarheid. Dit was niet nodig, zorgde alleen voor een overbelasting van opslag en indexering - de gegevens konden niet efficiënt worden geanalyseerd.