GUID primaire / étranger Key Dilemma SQL Server

inconvénient d'utiliser le GUID sur INT:

Les valeurs de chaîne ne sont pas aussi optimales que les valeurs entières pour les performances lorsqu'elles sont utilisées dans des jointures, des index et des conditions. Plus d'espace de stockage est nécessaire que INT.

Les GUDS générés doivent être partiellement séquentiels pour les meilleures performances (par exemple, la nouvelle suite () sur SQL 2005) et pour permettre l'utilisation d'index en clusters

Pour plus de détails:

http: //www.codinghorrorror .com / Blog / 2007/03 / Primary-Keys-IDS-Versus-Guids.html

http: // blog.sqlauthority.com/2010/04/28/sql-server-guid-vs-int-your-opinion/

Utiliser GUID ou INT pour PK dépend vraiment du scénario. Il y aura un coup de performance changeant de Int vers GUI. GUID est 4 fois plus grand qu'un int. Il y a un bon article ici sur les avantages et les inconvénients de l'utilisation de GUID.

Pourquoi devez-vous quand même changer d'entiers?

Les GUID ont un impact sur la performance relative à l'INT, mais cet impact peut être minimal en fonction de votre application, il n'ya donc aucun moyen d'être certain sans test. Une fois, j'ai converti une fois sur une application de l'INTS sur GUDS avec de très grandes tables avec de nombreuses clés étrangères faisant à la fois des modifications et des requêtes très lourdes (sur l'ordre de centaines de milliers de documents qui se retournent quotidiennement.) Les choses étaient plus lentes lorsqu'elles sont passées à travers un profileur , mais il n'y avait pas de différence notable du point de vue de l'utilisateur.

La réponse est donc "cela dépend". Comme toutes les choses traitant de la performance, vous ne pouvez pas vraiment être sûr que vous l'essayez.

GUIDS peut sembler être un choix naturel pour votre clé principale - et si vous le devez vraiment, vous pouvez probablement continuer à l'utiliser pour la clé primaire de la table. Ce que je recommandais vivement ne pas faire utilise la colonne GUID comme clé de clustering , laquelle SQL Server effectue par défaut, à moins que vous ne le disiez spécifiquement de ne pas.

Vous devez vraiment garder deux problèmes:

1) La clé primaire est une construction logique - l'une des clés candidates identifie de manière unique toutes les rangées de votre table. Cela peut être quelque chose, vraiment - un INT, un GUID, une chaîne - choisissez ce qui a le plus de sens pour votre scénario.

2) la touche de clustering (la colonne ou les colonnes qui définissent l'index en cluster sur la table) - c'est un physique physique lié ​​au stockage, et ici , un petit type de données stable, stable et toujours croissant est votre meilleur choix - Int ou Bigint comme option par défaut.

Par défaut, la clé principale d'une table SQL Server est également utilisée comme clé de clustering - mais cela n'a pas besoin d'être de cette façon! J'ai personnellement vu des gains de performances massives lors de la rupture de la clé principale / clustée principale basée sur le guid précédent en deux touches distinctes - la clé principale (logique) du GUID et de la clé de clustering (commande) sur une identité intégrée distincte (1, 1) colonne.

comme Kimberly Tripp - la reine de l'indexation - et d'autres ont déclaré beaucoup de fois - un GUID car la clé de clustering n'est pas optimale, car elle entraînera une fragmentation massive de page et d'index et généralement mauvaises Performance.

oui, je sais - il y a nouvelle suite () dans SQL Server 2005 et up - mais même ce n'est pas vraiment et totalement séquentiel et souffre ainsi des mêmes problèmes que le GUID - juste un peu moins en évidence donc.

Ensuite, il y a un autre problème à considérer: la clé de clustering sur une table sera ajoutée à chaque entrée de chaque index non clustered de votre table. Ainsi, vous voulez vraiment vous assurer que c'est aussi petit que possible. . En règle générale, une INT avec 2 milliards de lignes devrait être suffisante pour la grande majorité des tableaux - et comparé à un guid comme clé de clustering, vous pouvez épargner des centaines de mégaoctets de stockage sur disque et dans la mémoire du serveur.

Calcul rapide - Utiliser Int contre le GUID comme clé primaire et de clustering:

• Table de base avec 1'000'000 lignes (3,8 Mo contre 15,26 Mo)
• 6 index non clusterés (22,89 Mo vs. 91.55 Mo)

  Total: 25 Mo vs. 106 Mo - et c'est juste sur une seule table!

  Un peu plus de nourriture pour la pensée - Excellentes choses de Kimberly Tripp - Lisez-la, lisez-la à nouveau, digestez-la! C'est l'évangile d'indexation SQL Server, vraiment.

  • GUIDS Touche principale et / ou clé en cluster
  • Le débat d'index en cluster continue < / li>
  • jamais - Clé de clustering de neige - le débat sur l'index en cluster .......... à nouveau!

    Donc, si vous êtes vraiment DO Changer vos touches principales sur GUIDS - Essayez de vous assurer que la clé principale n'est pas la clé de clustering, et vous avez toujours un champ d'identité int sur la table utilisée. comme clé de clustering. Sinon, votre performance est sûre de faire le char et de prendre un coup sévère.