Les colonnes Integer / Identity sont souvent utilisées pour les clés primaires dans les tables de base de données pour un certain nombre de raisons. Les colonnes de clé primaire doivent être uniques, ne doivent pas pouvoir être mises à jour et ne doivent vraiment pas avoir de sens. Cela fait d'une colonne d'identité un très bon choix car le serveur obtiendra la valeur suivante pour vous, ils doivent être uniques et les entiers sont relativement petits et utilisables (par rapport à un GUID).
Certains architectes de bases de données soutiendront que d'autres types de données devraient être utilisés pour les valeurs de clé primaire et les critères "sans signification" et "non modifiables" peuvent être argumentés de manière convaincante des deux côtés. Quoi qu'il en soit, les champs entiers / d'identité sont assez pratiques et de nombreux concepteurs de bases de données trouvent qu'ils créent des valeurs clés appropriées pour l'intégrité référentielle.
- Le meilleur choix pour la clé primaire est les types de données entiers, car les valeurs entières sont traitées plus rapidement que les valeurs de type de données caractère. Un type de données caractère (en tant que clé primaire) doit être converti en valeurs équivalentes ASCII avant le traitement.
- La récupération de l'enregistrement sur la base de la clé primaire sera plus rapide dans le cas d'entiers comme clés primaires, car cela signifie que davantage d'enregistrements d'index seront présents sur une seule page. Ainsi, le temps de recherche total diminue. De plus, les jointures seront plus rapides. Mais cela s'appliquera si votre requête utilise la recherche d'index clusterisé et non l'analyse et si une seule table est utilisée. En cas d'analyse sans colonne supplémentaire, cela signifiera plus de lignes sur une page de données.
J'espère que cela vous aidera !
