Tabela historii bazy danych / tabela śledzenia

Obecnie chcę uporządkować tabelę śledzenia / historii w następujący sposób:

• PrimaryKey - ID
• OtherTableId - fk
• fieldName - nazwa pola, które śledzi
• OldValue
• Nowa wartość
• Nazwa Użytkownika
• CreateDateTime

Zasadniczo chcę mieć tabelę, która będzie śledzić kolejną historię tabel, przechowywać nazwę kolumny zmienionego pola z nową i starą wartością. Moje pytanie brzmi: czy ktoś może dziurawić w tym dziury? Ponadto, jaki jest najłatwiejszy sposób, aby w kolumnie fieldName wprowadzono tylko nazwę kolumny z tabel, które są śledzone? Obecnie moimi opcjami jest wyliczenie w usłudze, którą buduję, lub utworzenie innej tabeli statusu i ustawienie fieldName na fk. Jakieś lepsze pomysły?

Edytuj cel: Obecnie mamy tylko 2 pola, które chcemy śledzić. Jedno pole zostanie pokazane na stronie internetowej, aby wyświetlić historię, do drugiego pola będzie miał dostęp tylko jeden dział i będą mieli dostęp do widoku bazy danych, do którego mogliby zapytać. Przeszukaliby tylko to jedno pole, aby uzyskać informacje o tym, kto zmienił pole i co. Z tego powodu chcieliśmy ustawić go tam, gdzie pole bazy danych definiuje kolumnę tabeli, zamiast mieć dokładną kopię historii rekordów tabeli. Chcemy tylko śledzić dwa pola z możliwością dodawania lub usuwania pól w przyszłości.

Dzięki!

Dziury w otworach: co jeśli schemat bazy danych zostanie zmieniony w tym samym momencie w późniejszym czasie, a nazwa kolumny ulegnie zmianie lub kolumna zostanie całkowicie usunięta? Wiele systemów baz danych na to pozwala. Co stanie się z twoją „nazwą pola”?

Dla integralności danych: musisz upewnić się, że każda operacja aktualizacji lub usunięcia z pewnością zaktualizuje twoją tabelę śledzenia. Najlepiej to osiągnąć przez wywołanie procedury składowanej. Należy upewnić się, że tylko te procedury składowane mają dostęp do zapisu do tabeli śledzenia, aby nikt inny nie mógł zapisać niewłaściwych wartości.

Jeśli możesz żyć z rozwiązaniem specyficznym dla dostawcy db: większość systemów db ma tabele systemowe, w których przechowywane są informacje o schemacie (nazwy tabel, identyfikatory tabel, nazwy kolumn itp.). Możesz sprawdzić, czy możliwe jest ustawienie odniesienia klucza obcego do takiej tabeli systemowej. Pozwoliłoby to zastąpić nazwę pola identyfikatorem pola, jeśli baza danych obsługuje coś takiego.

W rzeczywistości, jeśli chcesz śledzić całe wiersze określonej tabeli, w tym wszystkie kolumny (a nie tylko niewielki podzbiór kolumn), powinieneś rozważyć sugestię @ sarfeast. Przeczytaj ten artykuł na temat wad modeli para-nazwa.

Najbardziej udane wdrożenie kontroli zmian (śledzenia historii), które widziałem, jest mniej ogólne i znacznie prostsze. Polega na utworzeniu tabeli dziennika zmian dla każdej tabeli, którą chcesz monitorować, zachowując identyczne nazwy kolumn i typy danych (z dodatkową kolumną dla znacznika czasu).

Cel końcowy, czyli to, co chcesz zrobić ze skontrolowanymi danymi, pomoże ocenić, jak odpowiednie może być każde podejście.

W skrócie: Musisz ustawić mechanizm Audit Trail dla tabel, które chcesz śledzić zmianę wartości.

Tabela pojedynczego audytu :

Utwórz tabelę, aby zapisać nazwę tabeli, nazwę pola i stare i nowe wersje danych. W przypadku tej metody zwykle rejestruje się zarówno stare, jak i nowe wersje danych oraz tylko te zmienione pola. Aby zaimplementować to w wyzwalaczach, wymagany jest albo klucz podstawowy w tabeli, albo tylko pojedyncze wiersze są aktualizowane.

Oto dobry post ze skryptami, jak to osiągnąć - tworzenie ścieżek audytu

Inne przydatne odniesienia do wyglądu:

• Audit Trail - Śledzenie zmian danych w bazie danych
• Pozostawienie ścieżki audytu w bazie danych

Możesz sprawdzić dokumentację projektu NHibernate Envers, aby znaleźć pomysły.

Zasadniczo masz jedną tabelę zmian, w której możesz dodać dodatkowe dane, takie jak znacznik czasu lub użytkownik. Następnie do każdej śledzonej tabeli pobierana jest dodatkowa tabela audytu ze wszystkimi kolumnami zduplikowanymi, fk do tabeli rewizji i typ rewizji (dodawanie, modyfikowanie, usuwanie). AFAIK, nie chciałbyś, aby twoje tabele audytu miały rzeczywisty FK do prawdziwej tabeli, ponieważ zapobiegnie to usunięciu.