Discussion :

[djelloharmel]

bonjour.
je suis nouveau en sql server 2008 que je trouve plus qu’intéressant. seulement voilà, en access, on peut indexer chaque champ d'une table "avec doublons" ou "sans doublons".
je voudrais savoir où sql server donne la main pour indexer un champ d'une table.

par ailleurs, la construction de certaines relations sous sql server me ramène le message d'erreur suivant:

Code :

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

1
2
3
4
5
table «*CONTRAT*» enregistrée
table «*CUBAGE*»
- Impossible de créer la relation «*FK_CUBAGE_CONTRAT*». 
Introducing FOREIGN KEY constraint 'FK_CUBAGE_CONTRAT' on table 'CUBAGE' may cause cycles or multiple cascade paths. Specify ON DELETE NO ACTION or ON UPDATE NO ACTION, or modify other FOREIGN KEY constraints.
Could not create constraint. See previous errors.

je voulais relier les tables "contrat" et "cubage" par le champ "contrat" qui est une clé primaire dans la table "contrat"
je voudrais savoir ce que signifie ce message et qu'est ce que je dois faire pour y remédier. je voudrais noter qu'en ACCESS, cette relation marche.

merci d'avance

[elsuket]

Bonjour,

seulement voilà, en access, on peut indexer chaque champ d'une table "avec doublons" ou "sans doublons".

C'est possible avec SQL Server :

Si la colonne doit contenir des valeurs uniques :

- Vous devez créer un index cluster
- Cela peut se faire avec le concepteur de table ...
- ... ou en ajoutant une contrainte de clé primaire : ALTER TABLE maTable ADD CONSTRAINT PK_maTable PRIMARY KEY(colonnes)
- ... ou en ajoutant une contrainte d'unicité et en spécifiant que l'index sous-jacent à celle-ci doit être cluster : ALTER TABLE maTable ADD CONSTRAINT UQ_maTable_colonnes UNIQUE (colonnes) CLUSTERED
- Notez qu'il ne peut y avoir qu'un seul index non-cluster par table

Si la colonne contient des valeurs qui peuvent être en double, vous pouvez créer un index non-cluster :

Code :

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

1
2
CREATE INDEX IX_maTable_mesColonnes
ON maTable (mesColonnes)

je voulais relier les tables "contrat" et "cubage" par le champ "contrat" qui est une clé primaire dans la table "contrat"
je voudrais savoir ce que signifie ce message et qu'est ce que je dois faire pour y remédier. je voudrais noter qu'en ACCESS, cette relation marche.

Sans le code et la structure des tables, difficile de vous aider ...

@++

[SLE]

Notez qu'il ne peut y avoir qu'un seul index non-cluster par table

C'est le contraire, non ? Un seul index CLUSTERED et plusieurs NON CLUSTERED

[fsmrel]

Bonjour,

Si la colonne doit contenir des valeurs uniques :
- Vous devez créer un index cluster

Si la colonne contient des valeurs qui peuvent être en double, vous pouvez créer un index non-cluster :

Un index de type NON UNIQUE (valeurs en double acceptées) peut être CLUSTER, en conséquence de quoi le (ou les) index de type UNIQUE branchés sur une table peuvent ne pas être CLUSTER, quels qu'ils soient.

Cela dit, qu'il soit UNIQUE ou pas, le choix de l'index CLUSTER est crucial, puisqu'on ne peut en avoir qu'un seul par table comme le rappelle SLE .

[fsmrel]

Venons-en à votre message d’erreur. Vu sa teneur, on peut penser que les relations entre CONTRAT et CUBAGE ressemblent à ceci (en conformité avec la théorie relationnelle) :


Le texte en bleu a trait au métabolisme des données (les structures des bases de données ne sont pas limitées qu’à leur seul aspect anatomique...) :

« CASCADE » signifie qu’à l’occasion de la suppression d’un contrat, des stimuli partent simultanément l’un par la gauche (chemin A) et l’autre par la droite (chemin B), avec pour effet la suppression simultanée des cubages (que sont-ce donc ces choses-là ?) en relation avec ce contrat (l’émission de stimuli vaut aussi pour la modification des clés primaires : les valeurs des clés étrangères de CUBAGE doivent être en permanence égales à celles des clés primaires de CONTRAT, même si changer la valeur d’une clé primaire est quelque chose qui mérite qu’on se fasse taper sur les doigts). A l’opposé, si l’option retenue est « NO CASCADE » (RESTRICT ou NO ACTION selon les SGBD), la suppression d’un contrat n’est possible que si ce contrat n’est pas référencé, car s’il l’est, la tentative échouera.

Dans le contexte ACCESS, l’équivalent du diagramme ci-dessus est le suivant (ACCESS est vraiment très mauvais pour représenter les diagrammes...) :


Le problème avec SQL Server est que, parce que les stimuli peuvent emprunter deux chemins pour aller d’un point à un autre, en l’espèce les chemins A et B, alors si l’on a l’option « CASCADE » pour un chemin, l’option pour l’autre chemin doit impérativement être « NO ACTION » (le « NO CASCADE » de SQL Server). Cette exigence n’est pas normale et elle est due au fait que l’algorithme utilisé par ce SGBD est manifestement trop fruste. Ma remarque valait du reste pour DB2 quand enfin on put mettre en œuvre l’intégrité référentielle avec ce SGBD (c’était en 1988). La partie cocasse de cette affaire est qu’avec DB2, si pour un chemin, on retenait l’option « CASCADE », alors pour l’autre chemin c’était obligatoirement « CASCADE » itou ! On avait même droit à la justification de ce choix (désolé, je n’ai pas la justification valant pour SQL Server, mais un MVP palliera sans doute mon incurie) :


Il est évident qu’à la réflexion, du fait d’un algorithme trop fruste les arguments des parents de DB2 ne tiennent pas la route (pas plus que ceux des parents de SQL Server, ACCESS serait donc meilleur sur ce point ? ) Quoi qu’il en soit, le principe général de l’algorithme permettant de gommer les dangers évoqués par IBM est fourni par Chris Date, dans Database Explorations, Essays on The Third Manifesto and Related Topics, à la page 224.

En ce qui vous concerne, vous serez malheureusement obligé de vous plier aux exigences de SQL Server : « CASCADE » d’un côté et « NO ACTION » de l’autre... Soit vous le faites directement dans la base de données ACCESS, soit vous interceptez la contrainte de clé étrangère coupable pour y modifier l’option. Si le choix du chemin à passer en « NO ACTION » est problématique d'un point de vue sémantique, vous pourrez exposer ici la difficulté qui se présente.

[SLE]

Waw ! ça c'est de la réponse !
+1

[elsuket]

C'est le contraire, non ? Un seul index CLUSTERED et plusieurs NON CLUSTERED

Héhé si, il était vraiment trop tard quand j'ai écrit ce message ... Merci de l'avoir relevé

Un index de type NON UNIQUE (valeurs en double acceptées) peut être CLUSTER, en conséquence de quoi le (ou les) index de type UNIQUE branchés sur une table peuvent ne pas être CLUSTER, quels qu'ils soient.

Cela dit, qu'il soit UNIQUE ou pas, le choix de l'index CLUSTER est crucial, puisqu'on ne peut en avoir qu'un seul par table comme le rappelle SLE .

Tout à fait, merci également d'avoir relevé ces deux erreurs.
Toutes mes excuses à djelloharmel.

Faut que je prenne des vacances moi

@++