Se dovessi affrontare il problema che hai menzionato, progetterei una tabella LOG come di seguito:
EntityName:(Stringa) Entità manipolata.(obbligatorio)ObjectId:entità manipolata, chiave primaria.FieldName:(Stringa) Nome campo entità.OldValue:(Stringa) Valore precedente campo entità.NewValue:(Stringa) Nuovo valore del campo dell'entità.UserCode:Identificatore univoco dell'utente dell'applicazione. (obbligatorio)TransactionCode:Qualsiasi operazione che modifichi le entità dovrà avere un codice di transazione univoco (come GUID) (obbligatorio),
In caso di aggiornamento su un'entità che modifica più campi, queste colonne saranno il punto chiave per tracciare tutte le modifiche in l'aggiornamento (transazione)ChangeDate:Data della transazione. (obbligatorio)FieldType:enumerazione o testo che mostra il tipo di campo come TESTO o Doppio. (obbligatorio)
Adottando questo approccio
Qualsiasi entità (tabella) potrebbe essere tracciata
I report saranno leggibili
Saranno registrate solo le modifiche.
Il codice della transazione sarà il punto chiave per rilevare le modifiche da parte di un singolo azione.
BTW
Store the changes in the entitychange table and then store the value
according to its datatype in entitychange_[bool|timestamp|double|string]
Non servirà, nella singola tabella avrai modifiche e tipi di dati
Use partitioning by HASH(entity_id)
Preferirò il partizionamento in base a ChangeDate o la creazione di tabelle di backup per changeDate sufficientemente vecchie per essere sottoposti a backup e rimozione dalla tabella LOG principale
Should I use another database system, maybe MongoDB?
Qualsiasi database ha i suoi pro e contro, puoi utilizzare il design su qualsiasi RDBMS. Un utile confronto tra database basati su documenti come MongoDB si trova qui
spero di essere utile.
