Discussion :

[grunk]

Bonjour à tous,

je me pose une question quant à l'utilisation d'un index d'unicité. J'ai une table très simple du type :

Code :

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

1
2
3
4
CREATE  TABLE IF NOT EXISTS `test`.`users_droits` (
  `idUser` INT UNSIGNED NOT NULL ,
  `idDroit` INT UNSIGNED NOT NULL )
ENGINE = InnoDB;

Dois je impérativement déclarer mes deux champs en Primary key ou puis je me contenter d'un index unique comme ceci :

Code :

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

CREATE UNIQUE INDEX `uniq_droit_user` ON `test`.`users_droits` (`idUser` ASC, `idDroit` ASC) ;

Tout en sachant que ces deux champs sont des clé étrangères :

Code :

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

1
2
CREATE INDEX `fk_user_droit_1` ON `test`.`users_users` (`idUser` ASC) ;
CREATE INDEX `fk_user_droit_2` ON `test`.`users_droits` (`idDroit` ASC) ;

Mysql ne semble pas raler quand j'utilise un index unique et non un primary.

Merci pour vos réponses

[Waldar]

Une clef primaire est l'association de deux contraintes : not null + unique.
Ce qui est bien votre cas !

Mais rien n'oblige une table à avoir une clef primaire.

[Maljuna Kris]

Saluton,
En fait tu peux très bien avoir autant de clés UNIQUEs dans une table que bon te semble (à la cohérence d'analyse près). Par contre, en toute logique il ne peut y avoir qu'une seule PRIMARY KEY, et dans le cas précis, qu'elle soit PRIMARY KEY ou UNIQUE ne change pas grand chose, cette table n'étant sans doute qu'un pivot entre deux autres tables pour permettre une association n,n

[CinePhil]

Ta table semble être issue d'une association entre les utilisateurs et les droits.

Quel est le MCD ?
1) user -0,n----avoir----0,n- droit
2) user -(0,1)----avoir----0,n- droit

Avec un logiciel de modélisation digne de ce nom, la génération du MLD va créer une table, que tu as le droit d'appeler 'users_droits' :
- Si c'est le 1), dont la clé primaire sera composée des identifiants des deux autres tables, donc le couple {idUser, idDroit}.
- Si c'est le 2), un utilisateur ne pouvant avoir qu'un seul droit, n'apparaîtra qu'une fois dans la table associative. Son identifiant (idUser) constituera donc la clé primaire.

En résumé :
- Si un utilisateur peut avoir plusieurs droits => clé primaire double {idUser, idDroit}.
- Si un utilisateur ne peut avoir qu'un seul droit => clé primaire simple {idUSer}.

EDIT :
C'est celui qui en dit le moins qui répond le plus vite !

[grunk]

Merci à tous pour vos réponses.
C'est en effet une table pivot du type user -0,n----avoir----0,n- droit.

Il n'y a donc pas de différence de performance entre utiliser une clé primaire double (idUser,iddroit) ou un index d'unicité double (sur idUser,iddroit) ?

[Maljuna Kris]

Il n'y a donc pas de différence de performance entre utiliser une clé primaire double (idUser,iddroit) ou un index d'unicité double (sur idUser,iddroit) ?

Ça je n'en sais fichtre rien.

[grunk]

Petit précision qui m'oriente dans mon choix.

Sous mysql workbench , quand j'utilise un index d'unicité plutôt qu'une clé primaire double, la relation entre la table parent et la table enfant n'est pas identifié alors qu'elle devrait l'être (l'enfant n'a pas lieu d'exister si le parent n'existe pas).

En revanche si j'utilise une clé primaire la relation est bien identifiée

[Maljuna Kris]

Mouaisfff

C'est normalement plutôt corrélé à la présence d'une FOREIGN KEY l'association entre tables.

[CinePhil]

Merci à tous pour vos réponses.
C'est en effet une table pivot du type user -0,n----avoir----0,n- droit.

Il n'y a donc pas de différence de performance entre utiliser une clé primaire double (idUser,iddroit) ou un index d'unicité double (sur idUser,iddroit) ?

A mon avis non.
La clé primaire est un index UNIQUE donc :
- Au niveau performance d'interogation, c'est un indexé donc c'est optimal.
- Au niveau performance d'ajout, c'est pareil qu'un index UNIQUE puisqu'ils vérifient tous deux l'unicité de l'insertion.

La seule contrainte supplémentaire de la clé primaire par rapport à l'index UNIQUE, c'est la vérification NOT NULL, pour autant que les colonnes composant un index UNIQUE ne soient pas par ailleurs déclarées NOT NULL. Ca doit prendre un petit paquet de microsecondes à chaque insertion ?

Conclusion : Ne te casse pas la tête ! Dans ton cas, tu mets une clé primaire double !