GUID vs INT IDENTITY [dupliquer]

Question

  

Double possible:
   Comment aimez-vous vos clés primaires?

Je suis conscient des avantages de l’utilisation d’un GUID, ainsi que de l’utilisation de INT en tant que PK dans une base de données. Considérant qu’un GUID est essentiellement un INT de 128 bits et un INT normal de 32 bits, l’INT est un économiseur d’espace (bien que ce point soit généralement sans objet dans la plupart des systèmes modernes).

Au final, dans quelles circonstances vous verriez-vous utiliser une INT comme PK contre un GUID?

Answer 1

Kimberley Tripp (SQLSkills.com) a un article sur l'utilisation des GUID en tant que clés primaires. Elle lui déconseille à cause des frais généraux inutiles.

Answer 2

Hormis le choix peu judicieux lorsque vous devez synchroniser plusieurs instances de base de données, les INT présentent un inconvénient que je n'ai jamais vu mentionné: les insertions ont toujours lieu à une extrémité de l'arborescence de l'index. Cela augmente les conflits de verrous lorsque vous avez une table avec beaucoup de mouvement (puisque les mêmes pages d'index doivent être modifiées par des insertions simultanées, alors que les GUID seront insérés partout dans l'index). Il peut également être nécessaire de rééquilibrer l'index plus souvent si une arborescence B * ou une structure de données similaire est utilisée.

Bien sûr, les int sont plus faciles à regarder lors des requêtes manuelles et de la construction de rapports, et la consommation d’espace peut s’additionner avec les utilisations de FK.

Je serais intéressé de voir toute mesure de la qualité, par exemple. En réalité, SQL Server gère les tables contenant beaucoup d’insert avec les clés d’IDENTITÉ.

Answer 3

Pour répondre à votre question: Au final, dans quelles circonstances vous verriez-vous utiliser une INT comme PK contre un GUID?

J'utiliserais un GUID si la version en ligne / hors ligne de mon système était telle que, dans la version hors ligne, vous pouvez enregistrer des données et que celles-ci soient retransférées sur le serveur un jour au cours d'une synchronisation. De cette façon, vous êtes certain de ne pas avoir la même clé deux fois dans votre base de données.

Answer 4

  

l’INT est un gain de place (bien que ce   le point est généralement discutable dans le plus moderne   systèmes).

Pas si. Cela peut sembler à première vue, mais notez que la clé primaire de chaque table sera répétée plusieurs fois dans la base de données dans les index et en tant que clé étrangère dans les autres tables. Et il sera impliqué dans presque toutes les requêtes contenant sa table - et de manière très intensive lorsqu'il s'agit d'une clé étrangère utilisée pour une jointure.

De plus, rappelez-vous que les processeurs modernes sont très, très rapides, mais que la vitesse de la RAM n’a pas suivi. Le comportement du cache devient donc de plus en plus important. Et le meilleur moyen d’obtenir un bon comportement du cache est d’avoir des ensembles de données plus petits. Ainsi, la différence apparemment sans importance entre 4 et 16 octets pourrait bien entraîner une différence notable de vitesse. Pas nécessairement toujours - mais c'est quelque chose à considérer.

Answer 5

Nous avons des guides dans nos logiciels d’entreprise très complexes partout. Fonctionne bien.

Je pense que les guides sont sémantiquement plus appropriés pour servir d'identificateurs. Il est également inutile de s’inquiéter inutilement des performances tant que vous n'êtes pas confronté à ce problème. Attention à l'optimisation prématurée.

La migration de bases de données présente également un avantage. Avec Guids, vous n'aurez aucune collision. Si vous essayez de fusionner plusieurs bases de données où les ints sont utilisés pour l'identité, vous devrez remplacer leurs valeurs. Si ces anciennes valeurs ont été utilisées dans les URL, elles seront désormais différentes à la suite de l'impact du référencement.

Answer 6

Lors de la comparaison de valeurs telles que la relation entre la clé primaire et la clé étrangère, le paramètre INT sera plus rapide. Si les tables sont correctement indexées et que les tables sont petites, vous ne verrez peut-être pas beaucoup de ralentissement, mais vous devrez l'essayer pour en être sûr. Les INT sont également plus faciles à lire et à communiquer avec d’autres personnes. C'est beaucoup plus simple à dire, "Pouvez-vous regarder l'enregistrement 1234?" au lieu de "Pouvez-vous regarder la fiche 031E9502-E283-4F87-9049-CE0E5C76B658?"

Answer 7

Certains systèmes d’exploitation ne génèrent plus de GUID basés sur des fonctionnalités matérielles uniques (CPUID, MAC) car cela simplifiait le suivi des utilisateurs (problèmes de confidentialité). Cela signifie que l'unicité du GUID n'est souvent plus aussi universelle que le pensent beaucoup de gens.

Si vous utilisez une fonction d'auto-identification de votre base de données, celle-ci pourrait en théorie être absolument sûre qu'il n'y a pas de duplication.

Answer 8

Si les données résident dans une seule base de données (comme la plupart des données des applications que nous écrivons en général), j'utilise un IDENTITY . C’est simple, conçu pour être utilisé de cette façon, ne fragmente pas l’index clusterisé et est plus que suffisant. Vous manquerez de place avec 2 milliards d’enregistrements (environ 4 milliards si vous utilisez des valeurs négatives), mais vous seriez de toute façon grillé si vous aviez autant d’enregistrements dans une table, puis vous avez un problème d’entreposage de données.

Si les données résident dans plusieurs bases de données indépendantes ou interfaces avec un service tiers, j'utilise le GUID qui a probablement déjà été généré. Un bon exemple serait une table UserProfiles dans la base de données qui mappe les utilisateurs d’Active Directory à leurs profils d’utilisateur dans l’application via leur objectGUID attribué par Active Directory.

Answer 9

Si vous envisagez de fusionner une base de données à un moment donné, c'est-à-dire pour une configuration de type de réplication multi-site, Guid vous évitera beaucoup de problèmes. Mais à part ça, je trouve que Int est plus facile.

Answer 10

Je pense toujours que les PK devraient être numériques si possible. N'oubliez pas que les GUID sont des clés de connexion signifient probablement qu'ils sont également utilisés dans d'autres tables en tant que clés étrangères, donc la pagination, l'index, etc. seront plus importants.

Answer 11

Je pense que la base de données est également importante. Du point de vue de MySQL - plus le type de données est petit, plus la performance est rapide.

Il semble que cela soit vrai pour int vs GUID aussi - http://kccoder.com/mysql/uuid-vs-int-insert -performance /

Answer 12

J'utiliserais le GUID en tant que PK uniquement si cette clé est liée à une valeur similaire. Par exemple, l'ID utilisateur (les utilisateurs dans WinNT sont décrits avec des GUID) ou l'ID du groupe d'utilisateurs. Un autre exemple. Si vous développez un système distribué pour la gestion des documents et différentes parties du système à différents endroits du monde, vous pouvez créer certains documents. Dans ce cas, j’utiliserais le GUID, car il garantit que 2 documents créés dans différentes parties du système distribué n’auraient pas le même identifiant.

Answer 13

Un INT est certainement beaucoup plus facile à lire lors du débogage et beaucoup plus petit.

J'utiliserais toutefois un GUID ou similaire en tant que clé de licence pour un produit. Vous savez que ça va être unique, et vous savez que ça ne va pas être séquentiel.