Discussion :

[Narann]

Bonjour,

J’essaie de modéliser ceci:

• Table A
• Table B
• Table C

Table C a deux clefs: type et id. type est soit 0 soit 1.

• Si type est a 0, id représente l’id de la Table A.
• Si type est a 1, id représente l’id de la Table B.

Par quels mécanismes (contraintes) puis-je m'assurer que l’intégrité des données?

En plus concret: J'ai des objets très différents (exemple: Arbres dans la table A et voiture dans la table B) et j'aimerais pouvoir lier chacun des objets une tache (table C), tout en m'assurant de l’intégrité de mes données.

Comment gérer ça?

Je vous remercie d'avance,

Narann

[escartefigue]

Bonjour,

Un contrainte n'est pas applicable ici puisque l'identifiant sera soit dans la table des arbres, soit dans celles des véhicules
Seul un trigger permettrait de faire ce contrôle

Mais quel est l'intérêt de cette construction ? décrivez clairement votre besoin plutôt que la solution envisagée qui me semble scabreuse, il y a certainement d'autres solutions que celle que vous proposez

[Narann]

Merci pour les infos !

J’ai également posé cette question sur stack overflow qui me propose de passer par une table associative mais ça ne me garantit pas qu’une task est lié soit a A, soit a B.

Pour l’explication concrète. J’ai deux objets de type très différent que je stocke donc dans deux tables.

• Asset (Table A), qui porte un nom.
• AssetInstance (Table B), qui pointe vers un asset et porte un numéro.
• Task (Table C), qui défini un travail a faire, qui peut être lie soit a un Asset soit a un AssetInstance.

Dans mon exemple il n’y a que Asset et AssetInstance, mais en pratique, il y a d’autres objets qui peuvent se voir assigner une (ou plusieurs) tache(s).

Si vous avez des idées pour modéliser ça et assurer l’intégrité des données, je suis preneur.

[Sve@r]

Bonjour

Je viens rarement ici. Et donc peut-être un peu tard (3 mois après) mais sait-on jamais...

Je pense que ton modèle est "soit j'ai un asset qui est relié à un assetInstance, soit j'ai un asset seul" (style asset relié à [0, 1] assetInstance).
Ensuite, ton Task est soit relié à l'originel "asset", soit relié à son dérivé "assetInstance".
Moi, j'aurais dit "tout asset a obligatoirement un assetInstance". Ainsi, j'aurais relié "Task" à "assetInstance" lui-même relié à "asset" et l'intégrité de mes données serait protégée...

[Narann]

Moi, j'aurais dit "tout asset a obligatoirement un assetInstance". Ainsi, j'aurais relié "Task" à "assetInstance" lui-même relié à "asset" et l'intégrité de mes données serait protégée...

On est presque parti la dessus. En fait, un asset et un asset instance sont tous deux des entités et les taches sont relie a l’entité. Ceci permet de fabriquer d’autres type d’entité qui ont, elle aussi, des taches.

[Sve@r]

Exactement. Moi avec ma vision réduite de ton souci je voyais le "assetInstance" comme grand chef mais toi qui a une meilleure vision tu as un truc "entité qui est lui le vrai "grand chef" et "asset" et "assetInstance" y sont tous deux reliés mais c'est la même chose. L'important pour l'intégrité c'est que "Task" en soit lié qu'à un seul truc unique (et non tantôt un truc tantôt l'autre)...