Je pensais à enlever l'enfant table d'entités et de les stocker sous forme de données XML dans un champ de l'entité mère tableau
Chaque fois que vous changez un parent, vous allez créer une copie de les enfants: si les données parentales changent beaucoup, alors vous mangerez votre stockage assez rapidement. En outre, stocker tous les changements d'enfant dans un enregistrement parent unique aura tendance à gonfler le parent (comme avoir beaucoup d'enfants tend à), ce qui pourrait avoir des implications pour la performance de la récupération de données.
Il existe de nombreuses façons de stocker des données versionnées, mais ils se divisent en deux catégories:
- version actuelle dans un magasin, les versions historiques dans un autre magasin
- toutes les versions dans un seul magasin
Choisir entre ces approches dépend de ce que vous voulez faire avec les versions historiques. Sont-ils là juste pour le retour en arrière? Ou les utilisateurs vont-ils régulièrement consulter les changements?
Une autre complication qui ne s'applique pas toujours mais que je pense être pertinent ici (à cause de votre solution suggérée) est la relation entre les changements parent et enfant: quand vous montrez une version historique du parent devez-vous montrer les versions appropriées de l'enfant? Et vice versa, si vous montrez une ancienne version d'un enfant, avez-vous besoin d'afficher les versions appropriées de son parent (et de ses frères et sœurs)?
La principale chose que vous devez établir est: que feront la plupart des utilisateurs la plupart du temps? Prioriser cela. Si le cas d'utilisation le plus courant est regardez seulement les versions actuelles de tous les enregistrements alors vous devriez opter pour des tables séparées pour stocker les versions.
Si vous devez enregistrer les versions enfants qui s'appliquaient à une version parente donnée, vous pouvez introduire une table de structure supplémentaire (parent_id, parent_version, child_id, child_version). Maintenir cette table n'est pas trop onéreux quand vous avez seulement des tables pour un parent et un enfant. Là où ça devient difficile, c'est quand vous avez plusieurs enfants dont vous avez besoin de suivre.
Des sons comme vous pourraient finir par limiter l'extensibilité des données stockées dans l'entité enfant à l'avenir. Pourquoi ne pouvez-vous pas simplement avoir des tables parent_history et child_history qui stockent l'historique des modifications. c'est-à-dire simplement copier une réplique exacte des données avant qu'elles ne soient mises à jour dans la table d'historique. la table d'historique contiendrait un champ datetime à conserver lorsque le changement a eu lieu. Vous pouvez utiliser des déclencheurs pour faire la copie – Andrew