Vastus (18.01.2024 00:53): Andmebaasi kasutamise (sh andmemuudatuste jälgimist) nimetatakse auditeerimiseks (auditing). Andmebaasisüsteemid pakuvad sageli selleks erinevaid sisseehitatud võimalusi kuid kui neid ei ole või need pole sellised nagu vaja, siis trigerid on andmemuudatuste logimise realiseerimiseks sobilik valik. Artiklis pakutud lahendus on kahtlemata võimalik. Enne selle kasutusele võttu lugege palun siiski järgnevat.

Trigeripõhiste lahenduste üldine probleem (mistahes andmebaasisüsteemis)

• Kuna trigereid ei saa panna reageerima SELECT sündmustele, siis ei saa trigerite abil logida andmete vaatamist.

Trigeripõhise lahenduse üldine probleem PostgreSQLis

• Kui andmemuudatus ebaõnnestub, siis tühistatakse andmebaasisüsteemi poolt kõik vastavast transaktsioonis tehtud andmemuudatused ja kõik nende poolt algatatud muudatused (sh käivitunud trigerite tehtud muudatused). Seega ei saa trigerite abil logida ebaõnnestunud muudatusi. Oracles saaks näiteks andmemuudatuse logimise realiseerida autonoomse transaktsioonina, mis tähendab, et logi kirjutamine õnnestub isegi siis, kui muudatus, mis logi kirjutamise algatas, ebaõnnestub ja rullitakse tagasi.

Konkreetse trigeripõhise lahenduse probleemid/nõrkused/mõttekohad.

• Triger ei logi kõikide ridade kiiret kustutamist (TRUNCATE operatsioon).
• Kui UPDATE lause reas midagi ei muuda, siis operatsiooni toimumise kohta registreeritakse kirje ikkagi.
• UPDATE lause puhul logitakse ka need väljad, milles andmed ei muutunud.
• Tuleks kaaluda, kas veergude old_val ja new_val puhul kasutada tüüpi JSON või JSONB (erinevus on väärtuse sisemises esitusviisis), arvestades kummagi eeliseid ja puuduseis. PostgreSQL juhendmaterjalides on igatahes öeldud:
  • "In general, most applications should prefer to store JSON data as jsonb, unless there are quite specialized needs, such as legacy assumptions about ordering of object keys."
• Logitabeli maht läheb kiiresti väga suureks ja võiks mõelda selle sektsioonideks jagamisele (partitioning).

SIIN kirjeldatakse veel erinevaid võimalusi PostgreSQLi andmebaasis toimuvate andmekäitluse operatsioonide logimiseks. Juttu on:

• andmebaasisüsteemi sisseehitatud logimise funktsionaalsusest (log_statement = all), mis tuleb administraatori poolt sisse lülitata,
• universaalsest trigeripõhisest lahendusest (Audit trigger 91plus),
  • Küsimuses pakutud lahendusest eristab seda see, et saab logida TRUNCATE operatsioonide tulemusi, logitakse rohkem metaandmeid muudatuse kohta ja UPDATE operatsiooni puhul logitakse ainult muutunud väärtuseid.
• pgAudit laiendusest.

Veel üheks lahenduseks ajalooliste andmete hoidmisel oleks disainida tabelid nii, et nendes saaks hoida ka ajaloolisi andmeväärtuseid. Sellist lähenemist pakub näiteks ankurmodelleerimine (siin on veidi eesti keeles). Põhimõtteliselt tekib selle kasutamisel iga olemitüübi atribuudi kohta eraldi tabel. Tabelite mugavamaks kasutamiseks luuakse vaated ja funktsioonid. Arendustööd aitab automatiseerida modelleerimiskeskkond, kus on muuhulgas ka koodigeneraator PostgreSQL jaoks (arendatud ühe meie ülikooli magistritöö tulemusena). Kui kartust tekitab see, et suure hulga tabelite ühendamine vähendab jõudlust, siis seda aitab kiirendada tabelite elimineerimise teisendus, mida oskab teha ka PostgreSQL. Selles lõputöös (on küll Oracle näitel, aga siiski) katsetatud ankurmodelleerimise andmebaasi.

Selles magistritöös kirjeldatakse veel  ühte võimalust andmemuudatuste ajaloo säilitamiseks ja realiseeritakse märkimisväärne osa seda toetavast taristust (operaatorid, vaated, trigerid) PostgreSQL jaoks.