Gdybym miał do czynienia z problemem, o którym wspomniałeś, zaprojektowałbym tabelę LOG w następujący sposób:
EntityName:(Ciąg) Podmiot, którym manipulujemy. (obowiązkowe)ObjectId:Jednostka, którą manipulujesz, klucz podstawowy.FieldName:(String) Nazwa pola Entity.OldValue:(String) Stara wartość pola Entity.NewValue:(String) Nowa wartość pola Entity.UserCode:Unikalny identyfikator użytkownika aplikacji. (obowiązkowe)TransactionCode:Każda operacja zmieniająca encje będzie musiała mieć unikalny kod transakcji (np. GUID) (obowiązkowy),
W przypadku aktualizacji encji zmieniającej wiele pól, ta kolumna będzie kluczowym punktem do śledzenia wszystkich zmian w aktualizacja (transakcja)ChangeDate:Data dokonania transakcji. (obowiązkowe)FieldType:wyliczenie lub tekst przedstawiający typ pola, taki jak TEKST lub Podwójny. (obowiązkowe)
Przy takim podejściu
Dowolna jednostka (tabela) może być śledzona
Raporty będą czytelne
Tylko zmiany będą rejestrowane.
Kod transakcji będzie kluczowym punktem do wykrycia zmian przez pojedynczą akcja.
BTW
Store the changes in the entitychange table and then store the value
according to its datatype in entitychange_[bool|timestamp|double|string]
Nie będą potrzebne, w jednej tabeli będziesz mieć zmiany i typy danych
Use partitioning by HASH(entity_id)
Wolę partycjonowanie według ChangeDate lub tworzenie kopii zapasowych tabel dla changeDate, które są na tyle stare, że można je zarchiwizować i usunąć z głównej tabeli LOG
Should I use another database system, maybe MongoDB?
Każda baza danych ma swoje własne problemy i wady, możesz użyć projektu na dowolnym RDBMS. Przydatne porównanie baz danych opartych na dokumentach, takich jak MongoDB można znaleźć tutaj
mam nadzieję, że będzie pomocna.
