Discussion :

[eperdu]

Bonjour,
Je suis jeune developpeur et j aurai aime avoir l aide de mes ainés pour un probleme bien curieux (enfin pour moi en tout cas lol).
Voila, je dispose de deux tables (T1 et T2) dont l une possede plusieurs clé etrangere vers l autre...Je crée mes relations correspondantes (Ra et Rb) et decide d ajouter une regle de suppression en cascade pour chacune d entre elle.
Aucun probleme pour la premiere relation ainsi crée, mais lorsque je fais la meme opération pour la suivante, voila ce qu il m affiche:

- Impossible de créer la relation 'Rb'.
L'introduction d'une contrainte FOREIGN KEY 'Rb' sur la table 'T1' peut provoquer des cycles ou des accès en cascade multiples. Spécifiez ON DELETE NO ACTION ou ON UPDATE NO ACTION, ou modifiez d'autres contraintes FOREIGN KEY.
Impossible de créer la contrainte. Voir les erreurs précédentes.

Je me demande si cela ne surviendrai pas a cause de l impossibilite pour Sql Server de savoir si les valeurs des cles etrangere sur T1 ne seraient pas identique et qu ainsi il aurait le risque de supprimer deux fois la meme occurence de la table T2?
Sinon y aurait il un moyen de contourner ce souci? ou bien est ce moi qui manipule mal mes outils Microsoft?

[SQLpro]

Il est EXTREMENENT dangereux d'utiliser le mécanisme d'IR CASCADE. En effet imaginez que vous faisiez cela sur la relation suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
CLIENT => COMMANDE => LIGNE COMMANDE => LIVRAISON => PAIEMENT
avec les cardinalité moyennes suivantes :
1 client => 100 commandes  
1 commande => 10 détail de commande
1 commande => 3 livraison
1 livraison => 3 paiement.
 
En supprimant 1 client en IR cascade vous allez imposer à SQL Server une transaction qui va donc supprimer :
              1 ligne de client
            100 ligne de commande
100 * 10 = 1000 lignes de détail de commande
1000 * 3 = 3000 lignes de livraison
3000 * 3 = 9000 lignes de paiement
----------------
          13101 lignes supprimées dans 5 tables...

Vous risquez deux choses : que votre utilisateur attende un bon moment avant de pouvoir continuer d'utilise le SGBDR après avoir déclenché la suppression. Mais vous risquez pire : le blocage car pour la suppression de lignes il faut qu'aucun autre utilisateur ne soit en train de les manipuler. Au pire du pire vous risquez l'interblocage.

C'est pourquoi on utilise très rarement l'IR cascade en production.

C'est aussi pour cet raison que SQL Server interdit les références multiples, circulaires et autres en mode cascade et ce à juste titre !

A +

[eperdu]

Merci pour cette reponse, je suis quand meme etonné que cela ne soit pas gerer... , je vais devoir donc coder dans mon appli ...
Je ne comprends pas trop le but de cette fonctionnalite si elle ne peut gerer efficacement ce genre de probleme car dans mon cas, je desirai que la suppression en cascade fasse ce qu elle promet, c est a dire une suppression en cascade ...
Bon tant pis... merci beaucoup SQLPro

[Nabot_Milka]

C'est dommage le but d'un SGBD relationnelle, c'est de pouvoir faire des updates ou des deletes en cascade...

Pour ma part je n'active jamais le "ON DELETE CASCADE" c'est beaucoup trop dangereux pour les bases en prod. Le client perd son historique, en moyenne il n’aime pas trop, à juste titre.

Mais bon se voir bloquer sur le "ON UPDATE CASCADE", il faut m'expliquer...

Exple :
Le client rentre la fiche technique de son véhicule, on suppose que la clef primaire est la plaque d'immatriculation.

Il crée des tournées pour ce véhicule.

Le lendemain le chauffeur vient et l'averti qu'il a fait une erreur sur l'immatriculation.

SQL SERVER ne sait pas faire ? Le Client est donc obligé de recréer un autre véhicule et de lui réassigné les mêmes tournées parce le SGBD ne sait pas faire...

En gros il aura : 1 doublons et effectué une double saisie à cause du "ON UPDATE CASCADE".

Ou alors pire SQL SERVER permet d'utiliser le "ON UPDATE CASCADE" mais pas trop quand même, le développeur est peut être totalement incompêtant !!!

Bref...

[Erwan1978]

Dans ton exemple je m'interrogerais sur la pertinence d'une clé primaire qui peut bouger du jour au lendemain

[SQLpro]

Vous avez apparament mal compris ce que j'ais dit.

Je n'ais jamais dit que SQL Server ne savait pas gérer le mode d'IR CASCADE. Il le gère parfaitement.
ON UPDATE CASCADE et ON DELETE CASCADE.

Démonstration :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
CREATE TABLE T1 
(A INT PRIMARY KEY, 
 B INT);
 
CREATE TABLE T2 
(C INT PRIMARY KEY, 
 D INT FOREIGN KEY REFERENCES T1 (A) 
       ON UPDATE CASCADE 
       ON DELETE CASCADE);
 
INSERT INTO T1 VALUES (1, 1);
INSERT INTO T1 VALUES (2, 2);
 
INSERT INTO T2 VALUES (3, NULL);
INSERT INTO T2 VALUES (4, 1);
 
DELETE FROM T1 
WHERE  A = 1;
 
SELECT * 
FROM   T2;
 
C           D
----------- -----------
3           NULL
 
CREATE TABLE T3 (E INT PRIMARY KEY, 
 F INT FOREIGN KEY REFERENCES T2 (C) 
       ON UPDATE CASCADE 
       ON DELETE CASCADE)
 
INSERT INTO T1 VALUES (1, 1);
INSERT INTO T2 VALUES (4, 1);
INSERT INTO T3 VALUES (5, 4);
 
DELETE FROM T1 
WHERE  A = 1;
 
SELECT * 
FROM   T2;
 
SELECT * 
FROM   T3;
 
CREATE TABLE T4 (G INT PRIMARY KEY, 
 H INT FOREIGN KEY REFERENCES T2 (C) 
       ON UPDATE CASCADE 
       ON DELETE CASCADE);
 
INSERT INTO T1 VALUES (1, 1);
INSERT INTO T2 VALUES (4, 1);
INSERT INTO T3 VALUES (5, 4);
INSERT INTO T4 VALUES (6, 4);
 
DELETE FROM T1 
WHERE  A = 1;
 
SELECT * 
FROM   T2;
 
SELECT * 
FROM   T3;
 
SELECT * 
FROM   T4;

Etc...

Mais cela est DANGEREUX ! Un SGBD est fait pour traiter de multiples utilisateurs SIMULTANÉMENT. Si plusieurs font cela en même temps, le verrouillage nécessaire pour faire les suppressions de ligne va pénaliser de plus en plus toutes les utilisateurs jusqu'à devenir bloquant, voir interbloqué !
C'est pourquoi ce mode est à déconseillé totalement, sauf pour du bricolage...
C'est d'ailleurs pour cela qu'a été introduit les mode ON DELETE / UPDATE SET NULL et SET DEFAULT destiné à déporter les traitements de suppression aux heures creuses. ENcore faudrait-il que les développeurs sachent s'en servier et n'utilisent jamais que des vues pour toutes manipulation de données (lecture et mise à jours), ce qu'hélas peu d'entre eux font, oubliant par là même le 4 eme niveau de schéma du Dr. Codd : le schéma externe...

A +

[Nabot_Milka]

Il le gère parfaitement mais des fois il met un message disant qu'il ne peut pas le faire... Ce n’est pas super logique.

Ou alors, il estime le nombre de séquence sur une cascade. Mais bon il devrait mettre un warning, si on aime faire du bricolage, il nous gâche un peux notre plaisir.

Zut... je vais être obligé de réfléchir sur mes requêtes et la construction de ma BDD, pour ne pas surcharger le serveur .

Pour vous rassurer, je joue à l'avocat du diable. J'utilise MS SQL SERVER depuis peux et je n'utilise pas les cascades, trop risqué et trop gourmant en ressource.

Mon exemple était un peu bidon. Une clef primaire qui change tous les quatre matins, ce n’est pas judicieux.


Cordialement.

[Depite]

Bonjour à tous.
Je reprends cette discussion quelques années plus tard car je suis aujourd'hui confronté au problème avec SQL 2008 et je ne me souviens pas avoir eu le cas lors de mes développements précédents (essentiellement SQL 6.5, 2000 et un peu 2005).
Malgrès toutes les préconisations de bon sens que j'ai lu dans ce fil, je voulais -assez bêtement j'en conviens - effectuer le report de la modification d'une clé primaire en cascade sur la clé étrangère associée de plus d'une table liées.
Ca se révèle impossible et m'étonne beaucoup.
En effet, sans passer à des extrêmes comme évoqués dans le fil et qui nécessitent une gestion plus réfléchie, je suis d'accord pour dire que : ou bien le système assure l'intégrité référentielle - sans récursivité - ou bien il ne le fait pas... mais pas à moitié!
Je me trouve dans la situation où il va falloir décider quelles tables seront mise à jour automatiquement et les quelles le seront via un trigger qu'il va falloir rédiger et maintenir pour chaque clé étrangère concernée.
Je trouve que c'est pas top...