Ciao all,
 
Mettez-vous les clés étrangères en Index ?
 
Etant donné que la majorité des clauses WHERE contiennent des clé étrangères...
 
 

Il y a d'abord l'index principal.
En théorie, cela ne devrait être qu'un champ "id".
Mais en pratique, c'est souvent une combinaison de champs, par exemple "type_produit, no_produit".
Le champ type_produit sera très probablement une clé étrangère dans la petite table des types de produits. Cela n'a pas d'importance.
 
Ensuite, pour les autres index, cela dépend des requêtes de sélection. Que les champs de ces autres index soient des clefs étrangères ou non n'a pas d'importance.
 
La maladresse a éviter (je l'ai vu récemment) est de choisir un index qui n'est pas très discriminant. Par exemple, si on a 3 types de produits, et 30000 produits, il est inutile, et même nuisible de créer un index secondaire qui ne contient que le type de produit. Par contre, créer un index secondaire qui ne contiendra que le numéro de produit, pourra etre utile pour les requêtes où l'utilisateur ne saisit pas le type de produit.

Merci pour cette réponse très instructive olivthill, mongole de merde va.
 
Pi sinon, vous mettez les clés étrangère en index vous?

 
 
Seulement si les verrous sont gênants(je parle pour Oracle, mais ca doit etre valable pour SQL Server).
Je m'explique : si je mets à jour la table mère, un verrou est posé sur toute la table fille.
Si je crée au préalable un index sur la clef étrangère de la table fille, ce verrou se limitera aux lignes référencées dans la table mère qui sont en cours de mise à jour. Dans ce cas précis, c'est donc beaucoup moins pénalisant.
Pour moi, un index sur clef étrangère n'est donc pas tant utile en terme de performance qu'en terme de disponibilité.
 

Merci

(attends, là je quote, parceque faudrait pas que t'édites avant qu'un modérateur arrive...)
 
C'est quoi cette attitude ?
olivthill a effectivement répondu à côté de la plaque (quoique pas complètement, puisqu'il y a de sérieux éléments de réponse dedans), et ne mérite pas du tout ce genre de réponse, ok ?
 
j'espère que ça va te valloir au moins un ban ce comportement.
 
je comprends pour ainsi dire rien à la réponse de jielbi.
 
-- Edit : J'ai dit une bêtise, la FK ne crée pas systématiquement d'index
 
Donc comme disait Olivthill, cela dépend surtout de l'utilisation et de la justification d'un index ou non... En tout cas, rien d'automatique.
 
-- Re-edit : Mon SQL Server est aussi à la rue que moi aujourd'hui, donc même quand je crée un index sur un clé étrangère pour vérifier si un index existe, il passe par la PK (qui n'a pourtant rien à voir)
 
Du coup, je ne suis plus sûr de moi... Me semble bien que la FK crée automatiquement un index sur le champ donc... Là vu le comportement de mon SQL Server, je peux pas affirmer ou infirmer... Voir la doc du SGBD dans tous les cas.

 
À dans un mois.

(attends, là je quote, parceque faudrait pas que t'édites avant qu'un modérateur arrive...)  
 
Mais quote seulement OH grand justicier de la paix ! Que le paradis te soit ouvert !!! (je ne sais pas comment quoté, ce forum n'est pas très intuitif...)
 
C'est quoi cette attitude ?  
olivthill a effectivement répondu à côté de la plaque (quoique pas complètement, puisqu'il y a de sérieux éléments de réponse dedans), et ne mérite pas du tout ce genre de réponse, ok ?  
 
Ok man dsl ! Merci de me faire des leçon de vie, qu'est-ce que je ferais sans toi...
 
 
A dans un mois.. ou à jamais (c'est un privilège de ne plus a avoir à revenir dans cette decheterie de message   )

Création d'un multi pour détourner une sanction => ban à durée indéterminé.

à MagicBuzz : qu'est ce que tu ne comprends pas ?  
 
Si il n'existe pas d'index sur une clef etrangère, lors d'une mise à jour Oracle verrouille par défaut la table fille en mode Share (c'est à dire que seuls des SELECT sont autorisés sur la table).  
A partir du moment où il existe un index sur la clef étrangère, Oracle verrouille la table fille en mode Row Share, c'est à dire que seules les lignes modifiées sont lockées, ce qui est beaucoup moins pénalisant en TP.
Je ne vois pas comment t'expliquer autrement...  
 
C'est pour ca que je disais qu'un index sur clef étrangère est plus intéressant pour la disponibilité que pour les performances.
Et encore, je ne les crée qu'au cas par cas, l'abus d'index pouvant à l'inverse pénaliser les perfs...
 
Au fait, ce discours ne s'applique que pour Oracle, je ne connais pas suffisamment le fonctionnement des autres SGBD.
C'est clair cette fois ?  

ok, je ne savais pas ça.
pour moi, y'avais pas de lock lorsqu'on met à jour la table de référence (sauf si on modifie un ID et qu'on active le mode CASCADE -absolument à éviter-)
 
en tout cas, ça confirme ce qui me faisait penser au fait que la FK générait de facto un index sur le champ. mais j'ai été incapable de le vérifier avec SQL Server (et pour Oracle, je sais jamais comment consulter le plan d'exécution donc... )

 
Mais lol  
 
Il faut dire que ces personnes qui n'y connaissent absolument rien et qui étalent leurs fonds de connaissance, ça gave !
 
Je posais une question claire et l'autre me fait un cours de BDD pour novices sur MSSQL.
-------
 
   
 
Sinon dans MySQL, l'indexage des clés primaires est automatique...
 
Moi je parlais des clés étrangères...

Au passage, merci à jielbi.

quelqu'un a parlé de clés primaires ici ?
 
si tu sais pas lire une réponse, ni chercher de la doc par toi-même, ni réfléchir suffisament pour trouver une réponse dans ce qu'on a écrit, alors c'est clair que nos réponses qui s'adressent aux novices ne te concernent pas, t'as besoin de réponses pour noob.
 
parceque c'est clair que t'es un vrai warrior, en être à se poser ce genre de questions, ça montre une très grande maîtrise du fonctionnement d'un sgbd, c'est indéniable. c'est même tellement poussé comme réflexion que tu dépasses même celle de ceux qui ont écrit le moteur du SGBD, trop fort mon gars, t'ira loin. peut-être jusque chez les TT si tu continues sur ce ton.

 
Ça ne justifie pas les insultes, il y avait d'autres moyens de le faire savoir.

@ Magic :

"si tu continues sur ce ton" mais lol c'est une menace ?
Dans cette matière c'est clair que t'es un exemple
 
Et je ne me prends pas pour un "Warrior", juste que j'ai vu un article (étant donné que je ne sais pas chercher de la doc) qui disait que les champs indexés étaient parfois conseillés pour les clauses "WHERE"... D'où ma question... Mais comme on ne peut pas poser une question sans faire monter des excès de zèles par 2-3 trolls boutoneux on se comprend
 
Au fait, si mon ton vous plait pas, vous pouvez me ban, franchement... Pour ce que ça va changer dans ma vie

Un index, c'est son rôle d'optimiser les clauses WHERE.
 
Donc t'as pas de question à question à te poser : t'as des champs intensivement utilisés dans tes requêtes : tu les index, sinon, tu les laisse.
 
Ca n'a strictement aucun rapport avec le fait que ce soit une FK.
 
Et un index ça ne se pose que sur des champs qui servent de CRITERE, si tu as une FK entre "commande et client", un index sur "commande.client_id", ne te sert à rien lorsque tu lis le client rattaché à une commande, puisque tu ne fais pas de filtre dessus.
 
en revanche, si tu fais une recherche de toutes les commandes pour un client donné, alors oui, il te faut un index sur ce champ.
 
tout comme il t'en faudra un sur la date de commande si tu veux faire des stats chronologiques... pourtant la date n'a rien à voir avec une clé étrangère...
 
c'est la base absolue des index, et c'est rigoureusement ce qu'a dit olivthill dans son premier post, même si c'est un peu plus confus.
 
y'a pas de relation intuitive entre FK et nécessité d'un index, ce qui ne veut pas dire que t'en a pas besoin.
 
que tu te fasses ban, j'en ai rien à secouer. y'a juste un certain nombre de règles élémentaires, qui commence par l'humilité quand on arrive sur un forum et qu'on pose une question, qu'on doit respecter. quand t'es venu poster, t'as accepté une charte d'utilisation, qui en fait pourtant mention explicitement. tout comme les règles élémentaires de la vie en communauté le rappellent.