Discussion :

[ppphil]

Bonjour,
Je ne sais pas trop comment faire ni si je suis sur le bon forum.
Bref, j'ai posté sur le forum mssql le problème suivant et j'aimerais votre avis...

Admettons le schéma suivant :

Entre Table1 et Table2 la relation indique "on delete cascade"
Entre Table1 et Table3 la relation indique "on delete cascade"
Entre Table3 et Table2 la relation indique "on delete set NULL"

En ben ça, mssql ne le tolère pas. Apparemment il considère que si on supprime un item de Table1, les ligne correspondantes à Table3 dans Table2 ne pourront plus être mises à jour (NULL sur IDTable3) par la suppression des items dans Table3 via la contrainte entre Table1 et Table3.

Avec mysql ces contraintes sont parfaitement acceptées, et leur fonctionnalité assurée. Ce qui me semble logique. Ça n'est apparemment pas l'avis d'experts mssql...

Quelqu'un aurait-il un avis ?

[Maljuna Kris]

Saluton,
Hors de toute considération technique l'intérêt de cette relation triangulaire m'échappe.
Je ne parviens pas à imaginer un cas concret qui m'amènerait à modéliser ma base de données comme cela.
Soit je peux accéder à Table1 à partir de Table2 via Table3, soit je peux accéder à Table1 à partir de Table3 via Table2, mais l'une des associations me semble inutile.

[ppphil]

Excuse-moi j'ai été un peu laconique...

Table1 = des entreprises
Table2 = des collaborateurs
Table3 = des bureaux
Les collaborateurs peuvent avoir ou ne pas avoir de bureau.
Si je supprime un bureau, tous les collaborateurs de se bureau n'en ont plus. Ils bossent à la maison par exemple. Donc collaborateur.bureau = null
Si je supprime une entreprise, tous les collaborateurs disparaissent. Tous les bureaux également.

Ca, c'est l'exemple simplifié de mon problème.

En réalité, j'ai un affichage d'une entreprise. Soit :
- une entreprise qui possède des ateliers
- des ateliers qui possèdent des machines
Ce schéma là est la représentation physique de la réalité. Donc une machine ne peut pas exister si elle ne fait pas partie d'un atelier. Jusque ici, pas de problème.

Maintenant, sur l'interface de l'application, l'utilisateur peut créer sa propre structure d'entreprise pour ranger ces machines par groupes et ce de manière totalement libre.

Donc :
- une machine peut appartenir à un groupe ou non. -> machine.groupe = groupe ou NULL
- un groupe fait par contre forcément partie d'une entreprise

Alors :
- si je supprime l'entreprise, je supprime par contrainte les atelier et les machines d'un côté, les groupes de l'autre.
- si je supprime un groupe, je dois forcément mettre les références à ce groupe dans les machine à NULL...

Est-ce plus clair ?

[Maljuna Kris]

Si j'applique cela à ton schéma, table1 est la table des entreprises, si je supprime une entreprise

si on supprime un item de Table1,

les bureaux et les employés rattachés seront supprimés, donc il n'y a pas lieu de faire un quelconque "on delete set NULL" entre Table3 et la Table2.
Si je supprime un bureau (table3) il faut mettre NULL dans idTable3 de Table2, mais je n'ai pas touché à Table1.
La vraie question est : une FOREIGN KEY (idTable3 de Table2) peut-elle prendre une valeur NULL ?

[ppphil]

La vraie question est : une FOREIGN KEY (idTable3 de Table2) peut-elle prendre une valeur NULL ?

C'est peut-être là ou je bloque.
Voici ce que l'on m'a indiqué sur le forum mssql : (lien)

Entreprise -0,N------(situer)-------1,1- Bureau
Collaborateur -0,1---(affecter)----0,N- Bureau

La cardinalité 0,1 du collaborateur, entraine la création du table "de jointure" au niveau du MLD.

Alors effectivement, dans ce cas, les contraintes ne sont plus les mêmes.

J'aimerais quand même bien savoir à quoi sert une contrainte ON DELETE SET NULL ????

En tous cas merci beaucoup...

[Oishiiii]

J'aimerais quand même bien savoir à quoi sert une contrainte ON DELETE SET NULL ????

Comme l'explique parfois SQLPro, cela permet sur les très grosses BDD de reporter les suppressions la nuit, pour ne pas dégrader les performances des utilisateurs en journée par exemple.