Les GUID sont problématiques en tant que clés en cluster en raison du caractère aléatoire élevé. Ce problème a été abordé par Paul Randal dans la dernière colonne Q&A de Technet Magazine :J'aimerais utiliser un GUID comme clé d'index clusterisé, mais les autres soutiennent que cela peut entraîner des problèmes de performances avec les index. Est-ce vrai et, si oui, pouvez-vous expliquer pourquoi?
Maintenant, gardez à l'esprit que la discussion porte spécifiquement sur le cluster index. Vous dites que vous voulez utiliser la colonne comme 'ID', ce qui n'est pas clair si vous l'entendez comme clé en cluster ou simplement comme clé primaire. Généralement, les deux se chevauchent, donc je suppose que vous voulez l'utiliser comme index clusterisé. Les raisons pour lesquelles c'est un mauvais choix sont expliquées dans le lien vers l'article que j'ai mentionné ci-dessus.
Pour les index non clusterisés, les GUID ont encore quelques problèmes, mais pas aussi gros que lorsqu'ils sont la clé clusterisée la plus à gauche de la table. Encore une fois, le caractère aléatoire des GUID introduit des fractionnements de page et une fragmentation, que ce soit au niveau de l'index non clusterisé uniquement (un problème beaucoup plus mineur).
Il existe de nombreuses légendes urbaines entourant l'utilisation des GUID qui les condamnent en fonction de leur taille (16 octets) par rapport à un int (4 octets) et promettent une perte de performances horrible s'ils sont utilisés. C'est légèrement exagéré. Une clé de taille 16 peut être une clé encore très performante, sur un modèle de données correctement conçu. S'il est vrai qu'être 4 fois plus gros qu'un int se traduit par plus de pages sans feuilles de densité plus faible dans les index, ce n'est pas un réel souci pour la grande majorité des tables. La structure b-tree est un arbre naturellement bien équilibré et la profondeur de la traversée de l'arbre est rarement un problème, donc la recherche d'une valeur basée sur la clé GUID par opposition à une clé INT est similaire en termes de performances. Une traversée de pages feuilles (c'est-à-dire une analyse de table) ne regarde pas les pages non feuilles, et l'impact de la taille du GUID sur la taille de la page est généralement assez faible, car l'enregistrement lui-même est nettement plus grand que les 12 octets supplémentaires introduits par le GUID. Je prendrais donc le conseil par ouï-dire basé sur "16 octets contre 4" avec un grain de sel assez gros. Analysez au cas par cas et décidez si l'impact de la taille fait une réelle différence :combien d'autres colonnes sont dans le tableau (c'est-à-dire quel impact a la taille du GUID sur les pages feuilles) et combien de références l'utilisent (c'est-à-dire combien d'autres les tables augmenteront en raison du fait qu'elles doivent stocker une clé étrangère plus grande).
J'appelle tous ces détails dans une sorte de défense improvisée des GUID parce qu'ils ont eu beaucoup de mauvaise presse ces derniers temps et certains sont immérités. Ils ont leurs mérites et sont indispensables dans tout système distribué (au moment où vous parlez de mouvement de données, que ce soit via la réplication ou le cadre de synchronisation ou autre). J'ai vu de mauvaises décisions prises sur la base de la mauvaise réputation du GUID lorsqu'elles ont été évitées sans considération appropriée. Mais c'est vrai, si vous devez utiliser un GUID comme clé groupée, assurez-vous de résoudre le problème du caractère aléatoire :utilisez des GUID séquentiels si possible.
Et enfin, pour répondre à votre question :si vous n'avez pas de précision raison d'utiliser des GUID, utilisez des INT.
