Discussion :

[jlbrd]

Bonjour,

Soit les deux tables suivantes:
Table1 : id (PK, uniqueidentifier), champx1, champy1
Table2 : id_table1 (FK, uniqueidentifier), champx2, champy2

La question est simple: Le performance seraient-elles meilleures en ajoutant à table2 un id (PK, uniqueidentifier) en sachant que ce nouveau champ ne serait pas utilisé dans des jointures ?


Merci

[sevyc64]

Quel est le rôle d'une clé primaire ?

Une clé primaire sert avant tout à identifier de manière certaine et unique chaque enregistrement de la table.
Il n'est pas forcément nécessaire de rajouter un champ identifiant dans une table pour en faire la clé primaire. Si un des champs ou une combinaison des champs de la table rempli la condition d'identifier de manière unique et certaine chaque enregistrement, ce champ ou cette combinaison peuvent être déclarés comme clé primaire.

Dans ton exemple, si on suppose que la FK ne peut être présente qu'une et une seule fois dans la table, elle peut donc être aussi déclaré PK de la table. Par contre, s'il est possible de trouver dans cette table, plusieurs fois la référence à l'enregistrement parent, alors non la FK ne peut pas être PK

Quant à la question Faut-il systématiquement une PK, quel qu'elle soit, dans une table, quel qu'elle soit, ma réponse en guise de bonne pratique est Oui Absolument et ce même si au final cette PK ne devrait pas être utilisée dans les requêtes.


Niveau performance, si c'est la FK qui est le plus objet de recherche dans cette table, PK ou pas, ça changera pas grand chose. Ce qui changera par contre, c'est d'avoir un index sur ce champ.
(a noter que normalement sous SQLServer, le fait de déclarer un champ comme PK rajoute automatiquement un index sur ce champ, mais il est bon de vérifier si c'est le cas, et si c'est le cas avec une FK aussi)

[jlbrd]

Merci de cette réponse détaillée.
Question complémentaire:

Si maintenant table2 contient une PK composée, on aurait donc:

Table1 : id (PK, uniqueidentifier), champx1, champy1
Table2 : id_table1 (FK, uniqueidentifier), cle1, cle2, valeur
créée avec "constraint AK_ID_cle1_cle2 unique (id_table1, cle1, cle2)"

Dans ce cas une PK non composée serait-elle utile?

[sevyc64]

non, bien au contraire.

Si ta combinaison est suffisante pour garantie la fonctionnalité de PK, il ne faut pas une autre pk, il faut utiliser celle-là. Parce que le pendant de la PK, c'est que par sa fonction même, elle garantie l'unicité des valeurs sur les champs qui la compose. Avec la clé primaire sur la combinaison des 3 champs, tu te garantie l'impossibilité d'avoir plusieurs fois la même combinaison sur ces champs là. Si tu utilise une clé sur un champ ajouté pour ne pas avoir de clé composée, cette unicité n'est plus garantie sur cette combinaison de champ, il te faut éventuellement rajouter donc des contraintes supplémentaires.