Nie jestem pewien, czy istnieje jedno „najlepsze podejście”, jest tak wiele zmiennych, które należy wziąć pod uwagę, w tym jak daleko jesteś na ścieżce rozwoju.
Po zapoznaniu się z rozwiązaniami audytu opartymi na kodzie i db-trigger poniżej wymieniłem kilka komentarzy; Mam nadzieję, że widzisz, na jakim etapie jesteś (pod względem rozwoju), co może wpłynąć na te problemy:
- Jeśli musisz zmapować użytkownika, który zmienił dane (co zwykle robisz), wyzwalacze db będą musiały jakoś uzyskać te informacje. Nie jest to niemożliwe, ale więcej pracy i kilka sposobów podejścia do tego (użytkownik bazy danych wykonujący zapytanie, wspólna kolumna użytkownika w każdej tabeli itp.)
- Jeśli używasz wyzwalaczy bazy danych i polegasz na liczbie wierszy, których dotyczy problem, zwracanych z zapytań, musisz wyłączyć tę opcję w wyzwalaczach audytu lub zmodyfikować istniejący kod, aby uwzględnić je.
- Wyzwalacze bazy danych IMHO zapewniają większe bezpieczeństwo i oferują łatwiejszą ścieżkę do automatyzacji audytu, jednak nie są niezawodne, ponieważ każdy, kto ma odpowiedni dostęp, może wyłączyć wyzwalacze, modyfikować dane, a następnie ponownie je włączyć. Innymi słowy, upewnij się, że Twoje prawa dostępu do bazy danych są ścisłe.
- Posiadanie jednej tabeli dla historii nie jest złą drogą, chociaż będziesz mieć więcej pracy do wykonania (i danych do przechowywania), jeśli przeprowadzasz audyt historii dla wielu tabel, zwłaszcza jeśli chodzi o rekonstrukcję ścieżki audytu. Musisz również wziąć pod uwagę problemy z blokowaniem, jeśli istnieje wiele tabel próbujących zapisywać do jednej tabeli audytu.
- Inną opcją jest posiadanie tabeli historii kontroli dla każdej tabeli. Potrzebujesz tylko, aby każda kolumna w tabeli audytu była dopuszczalna do wartości null, a także przechowywała datę i godzinę działania (wstaw/aktualizuj/usuń) oraz użytkownika powiązanego z działaniem.
- Jeśli zdecydujesz się na opcję pojedynczej tabeli, chyba że masz dużo czasu na to, nie rób sobie zbytniego ochoty na przeprowadzanie audytu tylko aktualizacji lub usunięć, chociaż unikanie wstawek może być kuszące (ponieważ większość aplikacje robią to częściej niż aktualizacje lub usunięcia), rekonstrukcja historii audytu wymaga sporo pracy.
- Jeśli Twoje serwery lub dane obejmują wiele stref czasowych, rozważ użycie odpowiedniego typu daty i godziny, aby móc przechowywać i rekonstruować oś czasu, np. datę zdarzenia kontroli przechowywania w czasie UTC, a także przesunięcie strefy czasowej.
- Te tabele kontroli mogą stać się ogromne, więc przygotuj strategię, jeśli zaczną wpływać na wydajność. Opcje obejmują partycjonowanie tabel na różne dyski, archiwizację itp. Pomyśl o tym teraz, a nie wtedy, gdy stanie się to problemem :)
