Jeg er ikke sikker på, at der er én "bedste tilgang", der er så mange variabler at tage i betragtning, inklusive hvor langt nede i udviklingsvejen du er.
Efter at have været igennem både kodebaserede og db-trigger revisionsløsninger, har jeg listet nogle kommentarer nedenfor; Jeg håber, du kan se, hvor du er nu (med hensyn til udvikling), kan påvirke disse problemer:
- Hvis du har brug for at kortlægge den bruger, der har ændret dataene (hvilket du normalt gør), så skal db triggers på en eller anden måde hente disse oplysninger. Ikke umuligt, men mere arbejde og flere måder at gribe dette an på (db-bruger eksekverende forespørgsel, fælles brugerkolonne i hver tabel osv.)
- Hvis du bruger db-udløsere, og du er afhængig af antallet af berørte rækker, der returneres fra forespørgsler, skal dine revisionstriggere have dette deaktiveret, eller din eksisterende kode skal ændres for at tage højde for dem.
- IMHO db-triggere tilbyder mere sikkerhed og tilbyder en lettere vej til revisionsautomatisering, men de er ikke idiotsikre, da alle med passende adgang kan deaktivere triggerne, ændre data og derefter aktivere dem igen. Med andre ord, sørg for, at dine db-sikkerhedsadgangsrettigheder er stramme.
- At have en enkelt tabel til historik er ikke en dårlig vej at gå, selvom du vil have mere arbejde at gøre (og data at gemme), hvis du reviderer historik for flere tabeller, især når det kommer til at rekonstruere revisionssporet. Du skal også overveje låseproblemer, hvis der er mange tabeller, der forsøger at skrive til en revisionstabel.
- En anden mulighed er at have en revisionshistoriktabel for hver tabel. Du skal blot have hver kolonne i revisionstabellen for at være nullbar, samt gemme dato og tidspunkt for handlingen (indsæt/opdater/slet) og den bruger, der er knyttet til handlingen.
- Hvis du går med muligheden for enkeltbord, medmindre du har meget tid til at bruge på dette, skal du ikke blive for fancy med at prøve kun at revidere på opdateringer eller sletninger, selvom det kan være fristende at undgå indsættelser (da de fleste apps gør dette oftere end opdateringer eller sletninger), at rekonstruere revisionshistorikken kræver en del arbejde.
- Hvis dine servere eller data spænder over flere tidszoner, så overvej at bruge en passende dato/klokkeslætstype for at kunne gemme og rekonstruere tidslinjen, dvs. gemme revisionsbegivenhedsdatoen i UTC samt inkludere tidszoneforskydningen.
- Disse revisionstabeller kan blive enorme, så hav en strategi, hvis de begynder at påvirke ydeevnen. Mulighederne omfatter tabelopdeling på forskellige diske, arkivering osv. tænk grundlæggende på dette nu og ikke når det bliver et problem :)