Discussion :

[olra72]

Bonjour,

J'ai trois types d'objets (affaires, devis, livrables) dans trois tables (t_Affaires, t_Devis, t_Livrables) avec chacune leur clé primaire (ID_Affaire, ID_Devis, ID_Livrable).

Pour des raisons X, j'ai besoin d'une table unique - t_Journal - regroupant divers "événements" relatifs - et plus ou moins communs - aux affaires, aux devis et aux livrables (création, annulation, report de date, changement de responsable, etc.).

Mon problème est de référencer dans la table t_Journal, l'objet - de nature variable - qui est à l'origine de l'événement.

J'ai pensé (et testé) diverses solutions : trois champs distincts dont un seul est non-vide ; usage d'un champ type en plus du champ ID ; champ ID unique avec recherche à posteriori (car les différents IDs sont textuelles et ne se recouvrent jamais), etc.

Mais je trouve tout ça inesthétique, complexe et peu efficace. Comment aborderiez-vous ça ?

Cordialement,

[olra72]

Je viens de penser à une solution de plus : définir une table t_JObjets, avec sa clé ID_JObjet, et relier mes affaires, devis, livrables à t_JObjets via une clé étrangère JObjet_ID !

Après tout, si mon journal souhaite renvoyer vers un objet commun, c'est bien qu'il existe un concept primitif "d'objet journalisable" (ou JObjet) dont les affaires, devis et livrables ne sont que des descendants (à l'exclusion d'autres objets d'autres tables).

Ça me paraît conceptuellement propre mais un peu lourd quand même. Pour ne pas avoir à créer de JObjet préalable pour toute création d'affaires, de devis ou de livrable, je pourrais attendre d'avoir au moins un événement journal à stocker pour le faire (dans le cas contraire, la valeur du JObjet_ID de l'objet considéré restera vide). Mais ... en fait, ça reviendra au même car j'ai toujours, pour tous ces objets, au moins un premier événement journal qui s'appelle "Création" (par qui et quand).

D'autres idées ?

[Paraffine]

J'aurais tendance à opter pour ID+type qui a l'avantage de rendre les données très lisibles.
Cela dit je fais de moins en moins de tables "multi-cibles" et pour peu que les cycles de vie des objets soient suffisamment différents je ferais 3 tables conçues pour partager des traitements commun (éventuellement chapeautées par une table commune? EDIT: d'un coté, la table commune, c'est fort laid. Mais cela dépend de ce que tu veux faire de ton Journal: relier des événements entre eux, par exemple ?).
Quelqu'un qui serait plus familiarisé avec une approche vraiment orientée objet devrait te donner des perspectives intéressantes ; je n'ai pas vu de forum ad hoc sur notre cher "Développez" ?

Merci de nous faire partager tes réflexions !
Cordialement.

[hyperion13]

Salut,
3 objets indépendants (t_affaire, t_devis et t_livrable) qui peuvent selon la circonstance changer d'état.

Dans ce cas, je serai amené à créer un 4ème objet (t_evenement) dans lequel je hiérarchiserai les évènements (annulation conclu, reporté, nouveau contact, etc.).
Je ne crée pas l'évènement "création" puisque si tu insères un nouvel enregistrement dans l'un de tes 3 objets, par définition l'affaire, le devis est créé.

Mais est-il envisageable qu'une affaire ou autre soit reportée plusieurs fois, qu'elle puisse être reportée et qu'il y ait un nouveau contact durant la négociation? Dans l'affirmative il faudra penser à créer d'autres tables pour définir des relations tuples.

Inutile de créer, pour ma part, la t_journal, dans la mesure où une requête te permettrait de pouvoir extrait des affaires ou autres selon un ou plusieurs évènements.