Si j'étais confronté au problème que vous avez mentionné, je concevrais une table LOG comme ci-dessous :
EntityName:(String) Entité manipulée.(obligatoire)ObjectId:Entité manipulée, clé primaire.FieldName:(Chaîne) Nom du champ de l'entité.OldValue:(chaîne) ancienne valeur du champ d'entité.NewValue:(chaîne) nouvelle valeur du champ d'entité.UserCode:identifiant unique de l'utilisateur de l'application. (obligatoire)TransactionCode:Toute opération modifiant les entités devra avoir un code de transaction unique (comme GUID) (obligatoire),
En cas de mise à jour sur une entité modifiant plusieurs champs, ces colonnes seront le point clé pour tracer tous les changements dans la mise à jourChangeDate:Date de la transaction. (obligatoire)FieldType:énumération ou texte indiquant le type de champ comme TEXT ou Double. (obligatoire)
Avec cette approche
Toute entité (table) pourrait être tracée
Les rapports seront lisibles
Seules les modifications seront enregistrées.
Le code de transaction sera le point clé pour détecter les modifications par un seul action.
BTW
Store the changes in the entitychange table and then store the value
according to its datatype in entitychange_[bool|timestamp|double|string]
Ne sera pas nécessaire, dans la table unique, vous aurez des modifications et des types de données
Use partitioning by HASH(entity_id)
Je préférerai partitionner par ChangeDate ou créer des tables de sauvegarde pour changeDate suffisamment anciennes pour être sauvegardées et supprimées de la table LOG principale
Should I use another database system, maybe MongoDB?
Toute base de données a ses propres avantages et inconvénients, vous pouvez utiliser la conception sur n'importe quel SGBDR. Une comparaison utile des bases de données basées sur des documents comme MongoDB pourrait être trouvé ici
j'espère être utile.
