Discussion :

[abrial]

Bonjour,

j'ai un table COMMANDE et une autre PRODUIT. Je peux avoir jusqu'à 8 produits dans une commande. Ce que je veux, c'est que si mes codes produits changent, alors les codes produits correspondant de la commande changent aussi.
Je crée donc un contrainte de clé étrangère pour mes 8 codes produits de la commande :
Table PRODUIT -> Table COMMANDE
PRO_Code -> COM_PRO_Code0 , UPDATE : CASCADE, DELETE : NO ACTION
PRO_Code -> COM_PRO_Code1 , UPDATE : CASCADE, DELETE : NO ACTION
PRO_Code -> COM_PRO_Code2 , UPDATE : CASCADE, DELETE : NO ACTION
...

Le problème est que SQL Server interdit d'avoir plusieurs contraintes en cascade dans la même table, et j'obtiens l'erreru suivante :
L'introduction d'une contrainte FOREIGN KEY 'NomContrainte' sur la table 'COMMANDE' peut provoquer des cycles ou des accès en cascade multiples.

Comment peut-on contourner le problème ?

Merci.

[SQLpro]

En utilisant les triggers.

Mais j'attire votre attention sur le fait que cela va vite devenir une base dont les performances seront lamentable en fonction de la volumétrie... En effet songez qu'avec un tel mécanisme un utilisateur lambda qui va changer un code d'un seul produit, peut se retrouver devant une transaction qui va durer quelques dizaines d'heures, vérouiller un maximum, introduire de la contention etc parce que ce produit là aura été commandé par plus de 5000 clients dans 80000 factures ! ... alors qu'il serait si simple de ne pas utiliser votre code produit comme clef de la table, de prendre un auto incrément comme clef, et d'ajouter à votre colonne CODE_PRODUIT une contrainte d'unicité. Dès lors le changement de valeur du code produit ne concernerait jamais qu'une seule ligne et tout vos problèmes sont résolus.

Venez suivre l'un de mes cours d'optimisation de bases de donées MS SQL Server... L'optimisation commence à la modélisation de la base, et c'est même la phase cruciale de l'optimisation, car 60 à 80% des problèmes de performances viennent d'un mauvais modèle de données !

A +

[abrial]

Merci pour la réponse. En effet, celà resoud mon problème. Mais un autre se pose à moi.
J'ai vu que certains SGBD proposent une instruction MATCH qui permet de spécifier que si la valeur d'une clé étrangère est à NULL, alors la contrainte n'est pas prise en compte.

Existe-t-il une instruction similaire dans SQL Server 2005 ?

Pour la formation, je vais en discuter avec mon responsable de projet. Proposez-vous des formations sur la création de bases de données SQL Server 2005 ? En relation avec VB.NET ou C# ? Avez-vous des locaux en région Rhone-Alpes.

Merci.

[SQLpro]

Bonjour,

MATCH n'est pas implémenté sous MS SQL Server. Cette clause est d'ailleurs inutile si la clef étrangère est monocolonne. En effet MATCH ne se propose de résoudre le cas que lorsque la clef est partiellement connue ce qui suppose une clef composée d'au moins deux colonnes.
Lisez l'article que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/cours/s...partie2#L7.3.1

(ou l'un de mes bouquins sur SQL... http://sqlpro.developpez.com/booksql05/)

Pour les cours, je donne les cours suivants dont le suis l'auteur :
SQO (Orsys) : http://www.orsys.fr/pdfCours/SQO.pdf
SQM (Orsys) : http://www.orsys.fr/pdfCours/SQM.pdf
et aussi les cours suivants chez LearningTree :
132 : http://www.learningtree.fr/courses/129qa.htm
535 : http://www.learningtree.fr/courses/535pf.htm

Certaines fois ces cours sont données à Lyon.

A +

[abrial]

Existe-t-il dans ce cas un moyen pour autoriser une clé étrangère à être NULL ?
Par exemple, dans une commande contenant au maximum 8 produits, tous les champs pour les identifiants de produit ne sont pas forcément remplis. Le client peut passer commande de seulement 1 produit. Mais SQL Server refuse de laisser une clé étrangère à NULL.

Merci.

[abrial]

Oups... Deux fois le même message ^^

[SQLpro]

1) prévoir 8 colonnes est anti relationnel, revoyez votre modèle de données.
2) ni SQL Server ni le langage SQL n'interdisent une clef étrangère à NULL. A mon avis votre modèle de données doit être nullissime (je parierait sur un modèle hiérarchique des années 60...) !

Conclusion : postez votre modèle, par exemple avec la définition des tables (ordres SQL CREATE TABLE...) et nous verrons ce que l'on peut faire !

A +