Ik weet niet zeker of er één "beste aanpak" is, er zijn zoveel variabelen om rekening mee te houden, inclusief hoe ver je bent op het ontwikkelingspad.
Nadat ik zowel op code gebaseerde als db-trigger auditing-oplossingen heb doorlopen, heb ik hieronder enkele opmerkingen vermeld; Ik hoop dat u kunt zien waar u zich nu bevindt (in termen van ontwikkeling) die van invloed kan zijn op deze problemen:
- Als u de gebruiker die de gegevens heeft gewijzigd in kaart moet brengen (wat u normaal doet), dan moeten db-triggers deze informatie op de een of andere manier ophalen. Niet onmogelijk, maar meer werk en verschillende manieren om dit te benaderen (db user die een query uitvoert, gemeenschappelijke gebruikerskolom in elke tabel, enz.)
- Als u db-triggers gebruikt en u vertrouwt op het aantal betrokken rijen dat wordt geretourneerd door query's, moet dit voor uw controletriggers zijn uitgeschakeld of moet uw bestaande code worden aangepast om hiermee rekening te houden.
- IMHO db-triggers bieden meer veiligheid en bieden een eenvoudiger pad naar automatisering van audits, maar ze zijn niet onfeilbaar, aangezien iedereen met de juiste toegang de triggers kan uitschakelen, gegevens kan wijzigen en ze vervolgens weer kan inschakelen. Met andere woorden, zorg ervoor dat uw DB-beveiligingstoegangsrechten strak zijn.
- Het hebben van één enkele tabel voor geschiedenis is geen slechte manier om te gaan, hoewel je meer werk te doen hebt (en gegevens op te slaan) als je de geschiedenis voor meerdere tabellen controleert, vooral als het gaat om het reconstrueren van het auditspoor. U moet ook rekening houden met vergrendelingsproblemen als er veel tabellen zijn die naar één controletabel proberen te schrijven.
- Het hebben van een controlegeschiedenistabel voor elke tabel is een andere optie. Je hoeft alleen elke kolom in de controletabel nullable te maken, evenals de datum en tijd van de actie (invoegen/bijwerken/verwijderen) en de gebruiker die aan de actie is gekoppeld.
- Als je kiest voor de optie voor één tabel, moet je, tenzij je veel tijd hebt om hieraan te besteden, niet al te veel zin krijgen om te proberen alleen te controleren op updates of verwijderingen, hoewel het verleidelijk kan zijn om invoegingen te vermijden (aangezien de meeste apps doen dit vaker dan updates of verwijderingen), het reconstrueren van de auditgeschiedenis kost behoorlijk wat werk.
- Als uw servers of gegevens meerdere tijdzones beslaan, overweeg dan om een geschikt datetime-type te gebruiken om de tijdlijn op te slaan en te reconstrueren, d.w.z. de datum van de auditgebeurtenis in UTC opslaan en de tijdzone-offset opnemen.
- Deze controletabellen kunnen enorm worden, dus zorg voor een strategie als ze de prestaties gaan beïnvloeden. Opties zijn onder meer tabelpartitionering op verschillende schijven, archivering, enz. Denk hier in principe nu aan en niet wanneer het een probleem wordt :)