Ако бях изправен пред проблема, който споменахте, щях да проектирам LOG таблица, както следва:
EntityName:(низ) Обект, който се манипулира.(задължително)ObjectId:Обект, който се манипулира, първичен ключ.FieldName:(Низ) Име на полето на обекта.OldValue:(Низ) Стара стойност на полето за обект.NewValue:(Низ) Нова стойност на полето за обект.UserCode:Уникален идентификатор на потребителя на приложението. (задължително)TransactionCode:Всяка операция, променяща обектите, ще трябва да има уникален код на транзакция (като GUID) (задължително),
В случай на актуализация на обект, променящ множество полета, тази колона ще бъде ключова точка за проследяване на всички промени в актуализацията (транслацията)ChangeDate:Дата на транзакцията. (задължително)FieldType:изброяване или текст, показващ типа поле като TEXT или Double. (задължително)
При този подход
Всеки обект (таблица) може да бъде проследен
Докладите ще бъдат четими
Ще се регистрират само промените.
Кодът на транзакцията ще бъде ключовата точка за откриване на промени от един единствен действие.
BTW
Store the changes in the entitychange table and then store the value
according to its datatype in entitychange_[bool|timestamp|double|string]
Няма да е необходимо, в единичната таблица ще имате промени и типове данни
Use partitioning by HASH(entity_id)
Ще предпочета разделяне по ChangeDate или създаване на архивни таблици за changeDate, които са достатъчно стари, за да бъдат архивирани и премахнати от основната таблица LOG
Should I use another database system, maybe MongoDB?
Всяка база данни се предлага със собствени проблеми и недостатъци, можете да използвате дизайна на всяка RDBMS. Полезно сравнение на бази данни, базирани на документи, като MongoDB може да се намери тук
надявам се да съм полезен.
