Quand dois-je utiliser la clé primaire ou l'index?
Quand dois-je utiliser une clé primaire ou un index?
Quelles sont leurs différences et quelle est la meilleure?
Fondamentalement, une clé primaire est (au niveau de l'implémentation) un type spécial d'index. Plus précisément:
- Une table ne peut avoir qu'une seule clé primaire et, à quelques exceptions près, chaque table doit en avoir une.
- Une clé primaire est implicitement
UNIQUE- vous ne pouvez pas avoir plus d'une ligne avec la même clé primaire, car son but est d'identifier de manière unique les lignes. - Une clé primaire ne peut jamais être
NULL, donc la ou les lignes qui la composent doivent être NON NULES
Une table peut avoir plusieurs index et les index ne sont pas nécessairement UNIQUE. Les index existent pour deux raisons:
- Pour appliquer une contrainte d'unicité (celles-ci peuvent être créées implicitement lorsque vous déclarez une colonne UNIQUE)
- Pour améliorer les performances. Les comparaisons pour l'égalité ou "supérieur/inférieur à" dans les clauses WHERE, ainsi que pour les JOIN, sont beaucoup plus rapides sur les colonnes qui ont un index. Mais notez que chaque index diminue les performances de mise à jour/insertion/suppression, vous ne devez donc les avoir que là où elles sont réellement nécessaires.
Différences
Une table ne peut avoir que ne clé primaire, mais plusieurs index.
A la clé primaire est unique, alors que l'index n'a pas à être unique. Par conséquent, la valeur de la clé primaire identifie un enregistrement dans une table, la valeur de l'index pas nécessairement.
Les clés primaires sont généralement indexées automatiquement - si vous créez une clé primaire, pas besoin de créer un index sur les mêmes colonnes.
Quand utiliser quoi
Chaque table doit avoir une clé primaire. Définissez une clé primaire qui garantira une identification unique de chaque enregistrement.
S'il y a d'autres colonnes que vous utilisez souvent dans des jointures ou dans des conditions où, n index peut accélérer vos requêtes. Cependant, les index ont une surcharge lors de la création et de la suppression d'enregistrements - quelque chose à garder à l'esprit si vous faites d'énormes quantités d'insertions et de suppressions.
Quel est le meilleur?
Aucun vraiment - chacun a son but. Et ce n'est pas que vous puissiez vraiment choisir l'un ou l'autre.
Je recommande de toujours vous demander d'abord quelle est la clé primaire d'une table et de la définir.
Ajoutez des index en fonction de votre expérience personnelle, ou si performances est en baisse. Mesurer la différence, et si vous travaillez avec SQL Server, apprenez à lire les plans d'exécution.
Les clés et les index sont des concepts très différents qui accomplissent des choses différentes. Une clé est une contrainte logique qui nécessite que les tuples soient uniques. Un index est une fonctionnalité d'optimisation des performances d'une base de données et est donc une caractéristique physique plutôt que logique de la base de données.
La distinction entre les deux est parfois floue car souvent une syntaxe similaire ou identique est utilisée pour spécifier les contraintes et les index. De nombreux SGBD créeront un index par défaut lors de la création de contraintes clés. Le risque de confusion entre la clé et l'index est regrettable car la séparation des préoccupations logiques et physiques est un aspect très important de la gestion des données.
En ce qui concerne les clés "primaires". Ce n'est pas un type de clé "spécial". Une clé primaire n'est qu'une clé candidate d'une table. Il existe au moins deux façons de créer des clés candidates dans la plupart des SGBD SQL et qui utilise la contrainte PRIMARY KEY ou une contrainte UNIQUE sur les colonnes NOT NULL. C'est une convention très largement observée que chaque table SQL a une contrainte PRIMARY KEY. L'utilisation d'une contrainte PRIMARY KEY est une sagesse conventionnelle et une chose parfaitement raisonnable à faire, mais elle ne fait généralement aucune différence pratique ou logique car la plupart des SGBD traitent toutes les clés comme égales. Certes, chaque table doit appliquer au moins une clé candidate, mais le fait que ces clés soient appliquées par des contraintes PRIMARY KEY ou UNIQUE n'a généralement pas d'importance. En principe, ce sont les clés candidates qui sont importantes, pas les clés "primaires".
Cela pourrait aider Retour aux principes de base: différence entre la clé primaire et l'index unique
Les différences entre les deux sont:
- Les colonnes qui constituent la clé primaire d'une table ne peuvent pas être NULL car, par définition, la clé primaire ne peut pas être NULL car elle permet d'identifier de manière unique l'enregistrement dans la table. La ou les colonnes qui composent l'index unique peuvent être annulées. Une note qui mérite d'être mentionnée ici est que différents SGBDR traitent cela différemment -> alors que SQL Server et DB2 n'autorisent pas plus d'une valeur NULL dans une colonne d'index unique, Oracle autorise plusieurs valeurs NULL. C'est l'une des choses à surveiller lors de la conception/développement/portage d'applications sur RDBMS.
- Il ne peut y avoir qu'une seule clé primaire définie sur la table, car vous pouvez avoir de nombreux index uniques définis sur la table (si nécessaire).
- En outre, dans le cas de SQL Server, si vous optez pour les options par défaut, une clé primaire est créée en tant qu'index cluster tandis que l'index unique (contrainte) est créé en tant qu'index non cluster. Ce n'est cependant que le comportement par défaut et peut être modifié au moment de la création, si nécessaire.
La clé primaire est par définition nique: elle identifie chaque ligne individuelle. Vous voulez toujours une clé primaire sur votre table, car c'est le seul moyen d'identifier les lignes.
Un index est essentiellement un dictionnaire pour un champ ou un ensemble de champs. Lorsque vous demandez à la base de données de trouver l'enregistrement où un champ est égal à une valeur spécifique, elle peut rechercher dans le dictionnaire (index) les bonnes lignes. C'est très rapide, car tout comme un dictionnaire, les entrées sont triées dans l'index permettant une recherche binaire. Sans l'index, la base de données doit lire chaque ligne de la table et vérifier la valeur.
Vous souhaitez généralement ajouter un index à chaque colonne sur laquelle vous devez filtrer. Si vous recherchez une combinaison spécifique de colonnes, vous pouvez créer un index unique contenant toutes ces colonnes. Si vous le faites, le même index peut être utilisé pour rechercher n'importe quel préfixe de la liste des colonnes de votre index. En termes simples (mais un peu inexacts), le dictionnaire contient des entrées consistant en la concaténation des valeurs utilisées dans les colonnes, dans l'ordre spécifié, afin que la base de données puisse rechercher des entrées qui commencent par une valeur spécifique tout en utilisant une recherche binaire efficace pour cette.
Par exemple, si vous avez un index sur les colonnes (A, B, C), cet index peut être utilisé même si vous ne filtrez que sur A, car il s'agit de la première colonne de l'index. De même, il peut être utilisé si vous filtrez à la fois sur A et B. Il ne peut cependant pas être utilisé si vous ne filtrez que sur B ou C, car ils ne sont pas un préfixe dans la liste des colonnes - vous avez besoin d'un autre index pour .
Une clé primaire sert également d'index, vous n'avez donc pas besoin d'ajouter un index convertissant les mêmes colonnes que votre clé primaire.