Nejsem si jistý, zda existuje jeden „nejlepší přístup“, existuje tolik proměnných, které je třeba vzít v úvahu, včetně toho, jak daleko jste na cestě vývoje.
Poté, co jsem prošel řešením auditování založeným na kódu i db-trigger, níže jsem uvedl některé komentáře; Doufám, že vidíte, kde se nyní nacházíte (z hlediska vývoje) by mohlo ovlivnit tyto problémy:
- Pokud potřebujete zmapovat uživatele, který změnil data (což běžně děláte), pak spouštěče db budou muset tyto informace nějak získat. Není to nemožné, ale více práce a několik způsobů, jak k tomu přistoupit (uživatel databáze provádějící dotaz, společný sloupec uživatele v každé tabulce atd.)
- Pokud používáte spouštěče databáze a spoléháte se na počet ovlivněných řádků vrácených z dotazů, pak je třeba u vašich spouštěčů auditu toto vypnout nebo upravit váš stávající kód tak, aby je zohledňoval.
- Spouštěče IMHO db nabízejí větší zabezpečení a nabízejí snazší cestu k automatizaci auditu, nejsou však spolehlivé, protože kdokoli s odpovídajícím přístupem může spouštěče deaktivovat, upravit data a poté je znovu povolit. Jinými slovy, zajistěte, aby vaše bezpečnostní přístupová práva db byla přísná.
- Mít jednu tabulku pro historii není špatný způsob, i když budete mít více práce (a ukládání dat), pokud auditujete historii pro více tabulek, zejména pokud jde o rekonstrukci auditní stopy. Musíte také zvážit problémy se zamykáním, pokud se do jedné auditní tabulky pokouší zapisovat mnoho tabulek.
- Další možností je mít tabulku historie auditu pro každou tabulku. Stačí, aby každý sloupec v tabulce auditu mohl mít hodnotu null, stejně jako ukládat datum a čas akce (vložit/aktualizovat/smazat) a uživatele přidruženého k akci.
- Pokud použijete možnost jedné tabulky, pokud tomu nebudete věnovat spoustu času, nezkoušejte auditovat pouze aktualizace nebo odstranění, i když může být lákavé vyhnout se vkládání (protože většina aplikace to dělají častěji než aktualizace nebo mazání), rekonstrukce historie auditu zabere docela dost práce.
- Pokud vaše servery nebo data pokrývají více časových pásem, zvažte použití vhodného typu data a času, abyste mohli uložit a rekonstruovat časovou osu, tj. uložit datum události auditu v UTC a také zahrnout posun časového pásma.
- Tyto tabulky auditu mohou být obrovské, proto mějte strategii, pokud začnou ovlivňovat výkon. Možnosti zahrnují rozdělení tabulek na různé disky, archivaci atd. v zásadě na to myslete hned a ne až to bude problém :)