Discussion :

[alassanediakite]

Salut
Je voudrais savoir l'utilité de mettre un index sur une clé étrangère.
Je viens de noter dans l'article de fsmrel que contrairement à ce que je pensais, ma conception de clé étrangère prenait plus de place. Ce qui ma poussé à voir du côté de sqlpro: certain SGBD posent automatiquement un index sur une clé étrangère. Peut être qu'ACCESS étant mon SGBD favori je ne m'en suis par rendu compte.
Merci d'avance.

[StringBuilder]

Je pense que ce genre d'automatisme n'est pas forcément heureux.

En effet :
- Il ne sera utile que dans de rares cas, où on interroge la table par la table de référence (genre, rechercher toutes commandes qui contienne un produit particulier... sauf que l'index sera généralement incomplet, par exemple on voudra filtrer aussi l'état de la commande)
- Il ne sera utilisé que si on a des contraintes "cascade" sur la foreign key, ce qui est fortement déconseillé.

Et vu qu'un index alourdi les opérations d'écritures, il est très inopportun de créer un index dont on ne se sert pas.

Bref, pour moi, il ne faut pas établir une règle "clé étrangère = index", c'est faux dans une majorité des cas. En revanche, ce qui est souvent vrai c'est "index = quelles clé étrangères vais-je mettre dedans ?"
=> Peut-être est-il intéressant de mettre un index sur le client, l'état de la commande, ainsi que la date de la commande, afin d'avoir facilement la liste des commandes validées durant les 12 derniers mois d'un client qui appelle le service téléventes. On aura certes, deux clés étrangères dans l'index, mais il n'y a pas de règle absolue qui permette de dire si telle clé ou telle clé doit être indexée, ni comment.

[alassanediakite]

Merci pour la réponse.
J'ai pas bien compris ça...

En revanche, ce qui est souvent vrai c'est "index = quelles clé étrangères vais-je mettre dedans ?"

et ça...

...l'état de la commande...

Pour une auto réponse:
Je pense que cela est très intéressant si les deux tables (ou plus) sont fréquemment utilisées ensemble et que le table "fille" compte beaucoup de lignes comme dans le cas de facture et detail_facture (vous l'avez dit). Ceci est à mon avis une conséquence de l'objet de l'index: accélérer les recherches.
Finalement c'était aussi simple que ça.
S'il n'y a pas d'avis complémentaire je pose "résolu"

[StringBuilder]

Pour moi, il n'y a pas de lien entre le fait que le champ soit une clé étrangère ou non, et le fait qu'il soit indexé ou non.

En revanche :
- Dans un écran de recherche, on est vite tenté de proposer des listes déroulantes basées sur ces clés étrangères pour faire des filtres
=> Donc il faut considérer quelles combinaisons de champs (dont un certain nombre sera des FK) seront souvent utilisées, afin d'en faire des index. Ceci n'a en revanche aucun lien avec le nombre d'entrées dans la table référencées.*

- Si tu met en place des contraintes "cascade" sur tes FK, et que tu comptes t'en servir "régulièrement", alors il faudra indexer unitairement les FK en question.

Mais l'aspect "systématique" n'a pas lieu d'être à mon avis.

* : Pour reprendre mon exemple de commande.

Je cherche les commandes validées d'un client depuis 12 mois.
J'ai donc dans mon index :
client_id references client(id)
etat_id references etat(id)
date_cde

La table "client" aura potentiellement des milliers de lignes
La table "etat" aura potentiellement moins de 5 lignes (créé, validé, annulé... et c'est tout)
date_cde n'est pas référencée

Si tu as beaucoup de client qui abandonnent leurs commandes en cours de route, il est impératif de pouvoir filtrer efficacement sur l'état de la commande. D'autant que pour calculer ton chiffre d'affaire, tu auras besoin de filtrer toutes les commandes dans un état donné. Le filtre sur l'état est donc aussi important que le filtre sur le client.

[alassanediakite]

Salut StringBuilder
J'ai dis "le nombre de lignes de la table fille" (qui fait référence à l'autre, pas qui est référencée!!!) . C'est la table fille qui contient la clé étrangère (dans le cas que j'ai dis ce sera "detail_facture"). A chaque fois que je veux imprimer une facture: la facture est vite trouver par l'index de la clé primaire, je parcours la table "detail_facture" pour trouver tous les détails liés. Alors si la table détail ne contient pas d'index sur la clé étrangère (pointant sur la clé primaire de facture) alors la table sera parcourue entièrement ce qui n'est pas acceptable avec avec un grosse volumétrie.
Mais en fait on tourne en rond sur le point
Merci pour la réponse.

[StringBuilder]

Dans ce cas effectivement, je suis d'accord avec ton analyse.

Mais quoi qu'en disent les intégristes de la modélisation, pour moi, une table "detail_facture" ne doit pas avoir pour clé primaire un bête "id" totalement inutile, mais une clé composée, dont fait partie la clé étrangère vers la facture (plus un auto-incrément pour les lignes de la facture par exemple)

Mais en règle générale :
- La clé étrangère n'est pas forcément (et même rarement) l'unique champ à indexer. Dans ton cas par exemple, on voudra trier les lignes de facture par ordre, donc il faut intégrer le numéro de ligne dans l'index, ce qui constitue une clé primaire sinon alternative.
- Un index sur clé étrangère n'est utile que lorsque tu as besoin de lister toutes les références à une ligne (ou un ensemble) de la table référencée.