Comment modéliser une relation de groupe dans la base de données et dans la POO?

Question

J'ai des instances de Item que j'aimerais avoir dans les groupes ItemGroup. Mais si un Item est déplacé vers un autre groupe d'articles, j'aimerais garder une trace du changement pour des raisons de responsabilité. Par exemple. J'ai besoin de savoir si un Item était dans un ItemGroup en octobre et un autre en septembre.

Comment dois-je modéliser ceci dans la base de données? Comment dois-je modéliser cela dans mes cours, OOP? Je peux voir quelques solutions différentes, mais elles sont toutes compliquées d'une certaine façon, donc je ne sais pas comment l'implémenter.

Soit je pourrais aller avec trois tables, ItemItemGroupGroupRelation et de garder un horodatage sur le GroupRelation. Si les informations sur l'élément sont mises à jour, je dois créer un nouvel élément et un nouveau GroupRelation. Si le groupe change d'élément, je dois créer un nouveau GroupRelation. Et si les informations du groupe sont modifiées, je dois créer un nouveau groupe et un nouveau GroupRelation. C'est complexe car je dois créer plusieurs nouveaux objets lors du changement.

Item 
+----+---------+-----+------+ 
| id | item_nr | ean | name | 
+----+---------+-----+------+ 

ItemGroup 
+----+------------+-----+ 
| id | group_name | vat | 
+----+------------+-----+ 

GroupRelation 
+----+---------+----------+-----------+ 
| id | item_id | group_id | timestamp | 
+----+---------+----------+-----------+ 

Une autre solution pourrait être d'avoir que deux classes Item et ItemGroup mais je dois avoir un horodatage dans les deux d'entre eux, je sais quand ils sont changés. Si le groupe est mis à jour, je dois mettre à jour tous les éléments qui appartiennent à ce groupe, donc c'est aussi complexe.

Item 
+----+---------+-----+------+----------+-----------+ 
| id | item_nr | ean | name | group_id | timestamp | 
+----+---------+-----+------+----------+-----------+ 

ItemGroup 
+----+------------+-----+-----------+ 
| id | group_name | vat | timestamp | 
+----+------------+-----+-----------+ 

Et il y a probablement d'autres solutions, l'une est peut-être de déplacer les anciennes versions vers une autre table. Mais alors est-il complexe de rechercher des données lorsque les données actuelles et anciennes doivent être recherchées. Ou je pourrais avoir une colonne prev_id ce lien vers l'ancienne version.

Y a-t-il quelqu'un qui a l'expérience de modèles de données similaires et qui a des recommandations? Y a-t-il des meilleures pratiques pour ce genre de problème?

Answer 1

Je voudrais aller avec votre Item, ItemGroup et GroupRelation comme une bonne conception normalisée avec une duplication minimale. Vos besoins d'audit peuvent être modélisés avec un tableau supplémentaire pour chaque tableau que vous devez auditer (par exemple: ItemAudit, ItemGroupAudit) qui contient les champs que vous devez auditer et un horodatage. Vous remplissez la table d'audit chaque fois qu'un champ vérifiable change. De cette façon, vous avez un historique et n'encombrez pas vos tables quotidiennes avec des données historiques.

Answer 2

De votre description, je pense qu'il existe un concept de GroupRelationHistory qui existe implicitement dans votre modèle. Je le ferais à une entité propre comme Item, ItemGroup et GroupRelation.

Dans le monde des objets que je ferais Item d'être au courant de son GroupRelationHistory, ce qui signifie qu'un objet Item a une référence à l'objet GroupRelationHistory. Essentiellement GroupRelationHistory est juste une liste de zéro, un ou plusieurs GroupRelation s.

L'introduction de ce concept devrait être soutenue par de réels besoins commerciaux. Rendez-vous chez votre client (ou chez un représentant) et demandez si l'historique est une entité à part entière et a une certaine valeur commerciale. Si oui, pensez à cette approche et affinez-la en fonction des besoins de l'entreprise. Pensez ensuite au modèle de base de données, qui dépend fortement des améliorations spécifiques.Si non, alors je ferais du concept d'histoire une fonctionnalité d'audit pure comme Oded suggéré.