GUIDs peuvent sembler être un choix naturel pour votre clé primaire - et si vous le devez vraiment, vous pourriez probablement argumenter pour l'utiliser pour la CLÉ PRIMAIRE de la table. Ce que je recommande fortement de ne pas faire, c'est d'utiliser la colonne GUID comme clé de clustering, ce que SQL Server fait par défaut, sauf si vous lui dites spécifiquement de ne pas le faire.
Dois-je utiliser GUID ou int pour la clé primaire ?
int est plus petit, plus rapide, facile à retenir, conserve une séquence chronologique. Et quant à Guid, le seul avantage que j'ai trouvé est qu'il est unique. Dans quel cas un Guid serait mieux que et int et pourquoi ? D'après ce que j'ai vu, int n'a aucun défaut sauf par la limite de nombre, qui dans de nombreux cas n'est pas pertinente.
Quand utiliser le GUID ?
Vous l'utilisez partout où vous avez besoin d'un identifiant garanti différent des autres. Les GUID sont généralement utilisés lorsque vous allez définir un ID qui doit être différent d'un ID que quelqu'un d'autre (hors de votre contrôle) définira Un tel endroit dans l'identifiant d'interface sur les contrôles ActiveX.
Quel type de données doit être utilisé pour la clé primaire ?
Les types de données entiers (nombre) sont le meilleur choix pour la clé primaire, suivis des types de données de caractères de longueur fixe. SQL Server traite les valeurs de type de données numérique plus rapidement que les valeurs de type de données caractère car il convertit les caractères en valeurs équivalentes ASCII avant le traitement, ce qui constitue une étape supplémentaire.
Est-il mauvais d'utiliser string comme clé primaire ?
La réponse courte: C'est parfaitement bien d'utiliser une chaîne comme clé primaire.
