Dans la documentation pour différents ORM, ils fournissent toujours un moyen de créer des index, etc. Ils mentionnent toujours de s'assurer de créer les index appropriés pour l'efficacité, comme si c'était une connaissance inhérente à un non-SQLer qui a besoin d'utiliser un ORM. Ma compréhension des index (en dehors de PK) est essentiellement la suivante : Si vous prévoyez de faire des requêtes LIKE (c'est-à-dire des recherches) basées sur le contenu d'une colonne, vous devriez utiliser un index plein texte pour cette colonne. Que devrais-je savoir d'autre concernant les index (principalement pour des raisons d'efficacité) ? J'ai l'impression qu'il y a un monde de connaissances à ma portée, mais il y a un énorme tapis de souris plié coincé dessous, donc je ne peux pas passer (Je ne sais pas pourquoi j'ai senti le besoin de dire ça, mais merci d'avoir fourni le canapé).
Réponses
Trop de publicités?
Pensez à un index à peu près comme l'index à la fin d'un livre. C'est une zone totalement séparée du contenu du livre, où si vous recherchez une valeur spécifique, vous pouvez aller à l'index et la chercher (les index sont ordonnés, donc trouver des choses là-bas est beaucoup plus rapide que de parcourir chaque page du livre).
L'entrée de l'index a un numéro de page, vous pouvez donc rapidement aller à la page recherchant votre sujet. Un index de base de données est très similaire ; c'est une liste ordonnée des informations pertinentes dans votre base de données (le(s) champ(s) inclus(es) dans l'index), avec des informations pour la base de données afin de trouver les enregistrements qui correspondent.
Donc... vous créez un index lorsque vous avez des informations que vous devez rechercher fréquemment. Les index normaux ne vous aident pas pour des recherches 'partielles' comme les requêtes LIKE, mais à chaque fois que vous devez obtenir un ensemble de résultats où le champ X a certaine(s) valeur(s), ils évitent au SGBD de devoir 'balayer' toute la table, à la recherche des valeurs correspondantes.
Ils aident aussi lorsque vous devez trier sur une colonne.
Autre chose à garder à l'esprit ; Si le SGBD vous permet de créer des index uniques avec plusieurs champs, assurez-vous d'examiner les effets de le faire, spécifiquement pour votre SGBD. Un index incluant plusieurs champs est probablement seulement pleinement (ou du tout) utile si tous ces champs sont utilisés dans une requête. En revanche, avoir de multiples index pour une seule table, avec un champ par index, peut ne pas être très utile (ou du tout) pour les requêtes qui filtrent/trient par plusieurs champs.
Vous avez mentionné les index Full Text et les PKs (Primary Keys). Ceux-ci sont différents des index normaux, bien qu'ils servent souvent des objectifs similaires.
Tout d'abord, notez qu'une Primary Key est généralement un index (dans MSSQL, un 'Clustered Index', en fait), mais cela n'a pas besoin d'être spécifiquement le cas. Par exemple, une PK MSSQL est un Clustered Index par défaut ; les indexes clusterisés sont spéciaux en ce sens qu'ils ne sont pas une partie de données séparée stockée ailleurs, mais les données elles-mêmes sont disposées dans la table dans l'ordre du Clustered Index. C'est pourquoi une PK populaire est une valeur int qui est auto-générée avec des valeurs séquentielles et croissantes. Ainsi, un Clustered Index trie les données dans la table spécifiquement par la valeur du champ. Comparez cela à un dictionnaire traditionnel; les entrées elles-mêmes sont ordonnées par la 'clé', qui est le mot à définir.
Mais dans MSSQL (consultez la documentation de votre SGBD pour vos informations), vous pouvez changer le Clustered Index pour être un champ différent, si vous le souhaitez. Parfois cela est fait sur des champs basés sur datetime.
Les index Full Text sont des bêtes de nature différente. Ils utilisent certains des mêmes principes, mais ce qu'ils font n'est pas exactement la même chose que les index normaux, que je suis en train de décrire. De plus : dans certains SGBD, les requêtes LIKE n'utilisent pas l'index full text ; des opérateurs de requête spéciaux sont nécessaires.
Ces indexes sont différents car leur intention n'est pas de trouver/trier sur toute la valeur de la colonne (un nombre, une date, un petit bout de donnée de type char), mais plutôt de trouver des mots/phrases individuels à l'intérieur des champs texte indexés.
Ils peuvent également souvent permettre de rechercher des mots similaires, des temps verbaux différents, des fautes d'orthographe courantes et ainsi de suite, et ignorer typiquement les mots bruit. La manière différente dont ils fonctionnent est la raison pour laquelle ils peuvent également nécessiter des opérateurs différents pour les utiliser. (encore une fois, consultez la documentation locale de votre SGBD pour plus d'informations!)
