Discussion :

[developpeur71]

Bonjour,

Mon probleme est le suivant :

J'ai une table Etablissement avec comme cle primaire codeEtablissement, ce codeEtablissement est une cle etrangere dans la table PointVente.

J'aimerai pouvoir a l'aide d'une saisie modifier ce codeEtablissement dans les deux tables via une procedure stockee, ca n'a pas marcher.
J'ai fait une recherche sur Internet et apparemment il faut activer/desactiver les contraintes mais ca ne marche pas

L'erreur suivante s'affiche :

"Impossible d'activer ou de desactiver la contrainte. Consulter les erreurs precedentes."

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
 
alter table PointVente nocheck constraint codeEtablissement
 
 
UPDATE PointVente
SET codeEtablissement  = @nouveaucodeEtablissement
WHERE codeEtablissement  = @codeEtablissement
 
UPDATE Etablissement 
SET codeEtablissement  = @nouveaucodeEtablissement
WHERE codeEtablissement  = @codeEtablissement
 
alter table PointVente check constraint codeEtablissement

Est ce que quelqu un peut m'aider ?

Merci d'avance

[SQLpro]

Une contrainte ne se désactive pas. Elle se détruit, et elle se remet.

Code :

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

1
2
ALTER TABLE ??? DROP CONSTRAINT xxx
ALTER TABLE ??? ADD CONSTRAINT xxx [....]

De plus pour une contrainte de clef étrangère, vous auriez pu opter pour le mode de gestion de la référence ON UPDATE CASCADE ce qui aurait fait que la modification de la valeur de référence aurait été répercutée dans la table fille sans avoir à débrancher la contrainte.

Enfin, il vaut mieux ne jamais utiliser des clefs sémantique (code par exemple) car ce genre de problème pèse notablement sur les performances. Il vaut mieux créer une clef primaire non sémantique du genre auto incrément et doubler cette clef primaire par une clef subrogée (code par exemple). De ce fait la modif du code n'entraine aucune autre modification que la seule donnée codifiée !

A +

[Sergejack]

et doubler cette clef primaire par une clef subrogée (code par exemple).

Est-ce que tu parles de la création d'un index ou de la création d'une clé composite ?

Par ailleurs je ne vois que des pertes à metter un entier autoincrémenté sans la moindre valeur sémentique plutôt qu'un entier qui en aurait.
Une table de code postaux-noms par exempleaurait une PK qui serait le code.

Puisque clustured index il y aura, autant qu'il ait un intérêt.

[Ptit_Dje]

L'interet d'utiliser une clef primaire sans aucune sémantique business (surrogate key) est, dans le cas ou le business change et nécessite la modification de la clef naturelle (natural key), qui elle a un sens business, de ne pas avoir à repercuter ces changements dans toutes les tables ayant une relation avec cette table parent.

Dans ce cas, on a un changement de valeur, ce qui a peu d'impact si l'on utilise le mode cascade pour mettre à jour la donnée.
Par contre, si le type de donnée ou la taille du champ de la clef naturelle venait à changer, par exemple passer de varchar(10) à varchar(20), cette modification de structure doit être reportée sur toutes les tables pointant sur cette clef.
Or si l'on utilise un entier auto-incrémenter sans valeur business, la modification de la clef naturelle n'entraine pas tous ces changements dans les tables ayant une référence sur la surrogate key car l'entier reste lui inchangé.

[Sergejack]

Perdre des performances à tout moment pour gagner du temps quand la structure changera contre toute attente...

Je préfère ne pas perdre ces performances et me débrouiller le jour où les codes changeront pour peu que cela arrive avant que le SGDB soit remplacé par une technologie post 2050.

[Ptit_Dje]

Sergejack,

Il n'est pas rare que les clefs business évoluent. J'ai déjà rencontré ce cas, et je peux vous assuré qu'en plus dans une base de données ou les relations entre les tables n'étaient pas implémentées et bien entendu pas de documentation de structure, ca a été assez sport... Ayant des effets de bords sur certains processus de fin de mois, alors que le changement avait été effectué beaucoup plus tot.

De plus, ce que vous mentionnez concernant les performances, n'est valable que lorsque la clef business est un entier. Car lors de jointures, si vous utilisez une clef business définie en varchar, le cout des jointures est plus élevé et contre-performant.
Lorsque vous prenez l'exemple des codes postaux, en effet si vous travailler dans une table ne visant qu'un seul pays, ces codes sont fixes et semblent une clef valide.
Ajoutez y les villes d'un pays dont la structure des codes postaux sont identiques à ceux dont vous aviez déjà, dans une table ayant une structure du genre: [code postal], [Ville]... Et vous arrivez déjà dans une solution problématique. Et pourtant ce n'est pas un gros changement, juste une expension du business dans un autre pays.

Bien entendu, il n'existe pas, comme dans beaucoup de cas en informatique, de solution parfaite n'ayant que des pros et aucun cons...
Personnellement, je préfère délivré une solution scalable, facilement maintenable et viable à long terme ayant des performances plus que correctes, plutot que délivrer une fusée qui pour chaque changement business nécéssite un projet en soit.
Et je pense que du coté budget, il est aussi plus interessant pour eux de miser sur une solution flexible et facilement adaptable plutot qu'une bombe à retardement qui pour chaque changement demandé nécéssite des jours de travail.

Comment penseriez vous à historiser l'évolution de données en utilisant comme clef primaire de votre table une clef business ?
On en vient ici à un élément de contexte qui ne doit pas non plus être mis de coté, OLTP ou DWH ?

Après, tout reste question de point de vue et de choix.