Avantages et inconvénients des clés de base de données GUID / UUID

J'ai travaillé sur un certain nombre de systèmes de bases de données dans le passé où le déplacement des entrées entre les bases de données aurait été beaucoup plus facile si toutes les clés de base de données avaient été des valeurs GUID / UUID . J'ai envisagé de suivre ce chemin à plusieurs reprises, mais il y a toujours un peu d'incertitude, en particulier concernant les performances et les URL non lisibles par téléphone.

Quelqu'un at-il beaucoup travaillé avec les GUID dans une base de données? Quels avantages pourrais-je obtenir de cette façon et quels sont les pièges probables?

Avantages:

• Peut les générer hors ligne.
• Rend la réplication triviale (par opposition aux int, ce qui la rend VRAIMENT difficile)
• Les ORM les aiment généralement
• Unique dans toutes les applications. Nous pouvons donc utiliser les PK de notre CMS (guid) dans notre application (également guid) et savoir que nous n'allons JAMAIS avoir de conflit.

Désavantages:

• Une plus grande utilisation de l'espace, mais l'espace est bon marché (euh)
• Impossible de commander par ID pour obtenir l'ordre d'insertion.
• Peut sembler moche dans une URL, mais vraiment, WTF faites-vous en train de mettre une REAL DB key dans une URL!? (Ce point est contesté dans les commentaires ci-dessous)
• Plus difficile à faire un débogage manuel, mais pas si difficile.

Personnellement, je les utilise pour la plupart des PK dans n'importe quel système de taille décente, mais j'ai été "formé" sur un système qui était reproduit partout, donc nous devions les avoir. YMMV.

Je pense que les données en double sont des déchets - vous pouvez obtenir des données en double comme vous le faites. Les clés de substitution sont généralement désapprouvées là où j'ai travaillé. Nous utilisons cependant le système de type WordPress:

• ID unique pour la ligne (GUID / autre). Jamais visible pour l'utilisateur.
• L'ID public est généré UNE FOIS à partir d'un certain champ (par exemple, le titre - faites-en le titre de l'article)

MISE À JOUR: Donc celui-ci obtient beaucoup + 1, et j'ai pensé que je devrais souligner un gros inconvénient de GUID PK: Clustered Indexes.

Si vous avez beaucoup d'enregistrements et un index clusterisé sur un GUID, vos performances d'insertion SUCERONT, car vous obtenez des insertions à des endroits aléatoires dans la liste des éléments (c'est le point), pas à la fin (ce qui est rapide)

Donc, si vous avez besoin d'insérer des performances, utilisez peut-être un INT auto-inc et générez un GUID si vous souhaitez le partager avec quelqu'un d'autre (c'est-à-dire le montrer à un utilisateur dans une URL)

@Matt Sheppard:

Disons que vous avez une table de clients. Vous ne voulez sûrement pas qu'un client existe dans le tableau plus d'une fois, ou beaucoup de confusion se produira dans vos services de vente et de logistique (surtout si les multiples lignes sur le client contiennent des informations différentes).

Vous disposez donc d'un identifiant client qui identifie le client de manière unique et vous vous assurez que l'identifiant est connu du client (sur les factures), afin que le client et le service client aient une référence commune au cas où ils auraient besoin de communiquer. Pour garantir l'absence d'enregistrements client dupliqués, vous ajoutez une contrainte d'unicité à la table, soit via une clé primaire sur l'identifiant client, soit via une contrainte NOT NULL + UNIQUE sur la colonne identifiant client.

Ensuite, pour une raison (à laquelle je ne peux pas penser), vous êtes invité à ajouter une colonne GUID à la table client et à en faire la clé primaire. Si la colonne d'identifiant client est maintenant laissée sans garantie d'unicité, vous demandez des problèmes futurs dans toute l'organisation car les GUID seront toujours uniques.

Un «architecte» pourrait vous dire que «oh, mais nous gérons la véritable contrainte d'unicité client dans notre niveau d'application!». Droite. La mode concernant les langages de programmation à usage général et (en particulier) les cadres de niveau intermédiaire change tout le temps et ne dépassera généralement jamais votre base de données. Et il y a de fortes chances que vous deviez à un moment donné accéder à la base de données sans passer par la présente application. == Problème. (Mais heureusement, vous et l'architecte êtes partis depuis longtemps, vous ne serez donc pas là pour nettoyer le gâchis.) En d'autres termes: maintenez des contraintes évidentes dans la base de données (et dans d'autres niveaux également si vous avez le temps).

En d'autres termes: il peut y avoir de bonnes raisons d'ajouter des colonnes GUID aux tables, mais ne tombez pas dans la tentation de réduire vos ambitions de cohérence dans les informations réelles (== non-GUID).

Pourquoi personne ne mentionne-t-il la performance? Lorsque vous avez plusieurs jointures, toutes basées sur ces méchants GUID, les performances passeront par le plancher, été là :(

Les GUID peuvent vous causer beaucoup de problèmes à l'avenir s'ils sont utilisés comme «uniqificateurs», laissant les données dupliquées pénétrer dans vos tables. Si vous souhaitez utiliser des GUID, pensez à conserver les contraintes UNIQUE sur d'autres colonnes.

Les principaux avantages sont que vous pouvez créer des identifiants uniques sans vous connecter à la base de données. Et les identifiants sont uniques au monde, vous pouvez donc facilement combiner les données de différentes bases de données. Ceux-ci semblent être de petits avantages mais m'ont permis d'économiser beaucoup de travail par le passé.

Les principaux inconvénients sont un peu plus de stockage nécessaire (pas de problème sur les systèmes modernes) et les identifiants ne sont pas vraiment lisibles par l'homme. Cela peut être un problème lors du débogage.

Il existe certains problèmes de performances comme la fragmentation d'index. Mais ceux-ci sont facilement résolubles (peigne guids par jimmy nillson: http://www.informit.com/articles/article.aspx?p=25862 )

Edit a fusionné mes deux réponses à cette question

@Matt Sheppard Je pense qu'il veut dire que vous pouvez dupliquer des lignes avec différents GUID comme clés primaires. Il s'agit d'un problème avec tout type de clé de substitution, pas seulement les GUID. Et comme il l'a dit, il est facilement résolu en ajoutant des contraintes uniques significatives aux colonnes non clés. L'alternative est d'utiliser une clé naturelle et ceux qui ont de vrais problèmes ..

Un autre petit problème à considérer avec l'utilisation de GUIDS comme clés primaires si vous utilisez également cette colonne comme index clusterisé (une pratique relativement courante). Vous allez prendre un coup sur l'insertion en raison de la nature d'un guide qui ne commencera pas séquentiel de toute façon, donc ce seront des sauts de page, etc. lorsque vous insérerez. Juste quelque chose à considérer si le système va avoir un IO élevé ...

identificateurs-clés-primaires-guids

Le coût des GUID en tant que clés primaires (SQL Server 2000)

Mythes, GUID et auto-incrémentation (MySQL 5)

C'est vraiment ce que tu veux.

UID Pros

• Unique sur chaque table, chaque base de données, chaque serveur
• Permet une fusion facile des enregistrements de différentes bases de données
• Permet une distribution facile des bases de données sur plusieurs serveurs
• Vous pouvez générer des ID n'importe où, au lieu d'avoir à aller-retour à la base de données
• La plupart des scénarios de réplication nécessitent de toute façon des colonnes GUID

Inconvénients du GUID

• C'est un énorme 4 fois plus grand que la valeur d'index à 4 octets traditionnelle; cela peut avoir de graves conséquences sur les performances et le stockage si vous ne faites pas attention
• Lourd à déboguer (où userid = '{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}'))
• Les GUID générés doivent être partiellement séquentiels pour de meilleures performances (par exemple, newsequentialid () sur SQL 2005) et pour permettre l'utilisation d'index clusterisés

Il y a une chose qui n'est pas vraiment abordée, à savoir l'utilisation d' ID aléatoires (UUIDv4) comme clés primaires nuira aux performances de l' index de clé primaire . Cela se produira, que votre table soit regroupée ou non autour de la clé.

Les RDBM garantissent généralement l'unicité des clés primaires et assurent les recherches par clé, dans une structure appelée BTree, qui est un arbre de recherche avec un facteur de branchement important (un arbre de recherche binaire a un facteur de branchement de 2). Maintenant, un ID entier séquentiel entraînerait les insertions à se produire un seul côté de l'arbre, laissant la plupart des nœuds feuilles intacts. L'ajout d'UUID aléatoires entraînera les insertions à diviser les nœuds feuilles sur tout l'index.

De même, si les données stockées sont principalement temporelles, il arrive souvent que les données les plus récentes soient accessibles et jointes le plus souvent. Avec des UUID aléatoires, les modèles n'en bénéficieront pas et toucheront plus de lignes d'index, nécessitant ainsi plus de pages d'index en mémoire. Avec des ID séquentiels, si les données les plus récentes sont le plus nécessaires, les pages d'index à chaud nécessiteraient moins de RAM.