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

@Matt Sheppard:

dites 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 lignes multiples au sujet du client contiennent des informations différentes).

ainsi vous avez un identifiant de client qui identifie de manière unique le client et vous vous assurez que l'identifiant est connu par le client (en factures), de sorte que le client et le personnel du service à la clientèle disposent d'une référence commune au cas où ils auraient besoin de communiquer. Pour garantir qu'aucun enregistrement client ne sera dupliqué, vous ajoutez une contrainte d'unicité à la table, soit par l'intermédiaire d'une clé primaire sur l'identifiant du client, soit par l'intermédiaire d'une contrainte non nulle + UNIQUE sur la colonne identifiant du client.

ensuite, pour une raison quelconque (à laquelle je ne pense pas), il vous est demandé d'ajouter une colonne de guidage à la table client et faire que le clé primaire. Si la colonne d'identification du client est maintenant laissée sans un caractère unique-garantie, vous demandez des problèmes futurs dans toute l'organisation parce que les GUIDs seront toujours uniques.

certains " architectes "pourraient vous dire que "oh, mais nous nous occupons de la réel contrainte UNIQUE client dans notre niveau d'application!". Droit. La mode à l'égard des langages de programmation À Usage général et (surtout) des cadres intermédiaires change constamment, et généralement jamais hors-vivre votre base de données. Et il y a de très bonnes chances que vous ayez à un moment donné besoin d'accéder à la base de données sans passer par la présente application. == Difficulté. (Mais heureusement, vous et l ' "architecte" êtes partis depuis longtemps, donc vous ne serez pas là pour nettoyer le désordre. En d'autres termes: maintenez des contraintes évidentes dans la base de données (et dans d'autres niveaux, si vous avez le temps).

en d'autres termes: il peut y avoir de bonnes raisons d'ajouter GUID colonnes aux tableaux, mais s'il vous plaît ne tombez pas dans la tentation de faire baisser vos ambitions pour la cohérence dans le réel (==Non-GUID) information.

les principaux avantages sont que vous pouvez créer des id uniques sans se connecter à la base de données. Et les id sont globalement uniques de sorte que vous pouvez facilement combiner des données de différentes bases de données. Cela semble être de petits avantages mais m'ont épargné beaucoup de travail dans le passé.

les principaux inconvénients sont un peu plus de stockage nécessaire (pas un problème sur les systèmes modernes) et les id ne sont pas vraiment lisibles par les humains. Cela peut poser un problème lors du débogage.

Il y a certains problèmes de performance comme la fragmentation de l'indice. Mais ceux-là sont faciles à résoudre (comb guids par jimmy nillson: http://www.informit.com/articles/article.aspx?p=25862 )

Modifier fusionné mes deux réponses à cette question

@Matt Sheppard je pense qu'il veut dire que vous pouvez dupliquer des lignes avec des Gids différents comme clés primaires. C'est un problème avec n'importe quelle sorte de clé de substitution, pas seulement des GUIDs. Et comme il l'a dit, il est facilement résolu en ajoutant des contraintes uniques signifiantes aux colonnes non-clés. L'alternative est d'utiliser une clé naturelle et ceux qui ont de réels problèmes..

Guid peut vous causer beaucoup de problème à l'avenir, si elles sont utilisées comme des "uniqifiers", laissant dupliqué données dans vos tables. Si vous souhaitez utiliser GUIDs, s'il vous plaît envisager de maintenir UNIQUE-contraintes sur d'autres colonne(s).

pourquoi personne ne parle de performance? Lorsque vous avez plusieurs jointures, tous basés sur ces vilaines GUIDs la performance va passer par le sol, été là : (

un autre petit problème à considérer avec l'utilisation de GUIDS comme clés primaires si vous utilisez également cette colonne comme un indice groupé (une pratique relativement courante). Vous allez prendre un hit sur insert en raison de la nature d'un guid ne pas commencer séquentielle dans de toute façon, donc leur sera page splits, etc Lorsque vous insérez. Juste quelque chose à considérer si le système va avoir un IO élevé...

primaire-clés-id-versus-guid

Le Coût de Guid comme Clés Primaires (SQL Server 2000)

Myths, GUID vs. Autoincrement (MySQL 5)

C'est vraiment ce que vous voulez.

UID Pros

• Unique à travers chaque table, chaque base de données, chaque serveur
• permet la fusion facile d'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 à la base de données
• la plupart des scénarios de réplication nécessitent des colonnes D'orientation de toute façon

GUID Cons

• C'est un énorme 4 fois plus grande que la valeur de l'indice traditionnel de 4 octets; cela peut avoir de graves conséquences sur la performance et le stockage si vous n'êtes pas prudent
• lourd à déboguer (où userid='{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}')
• les GUIDs générés doivent être partiellement séquentiels pour une meilleure performance (par exemple, newsequentialid () sur SQL 2005) et pour permettre l'utilisation des index groupés

il y a une chose qui n'est pas vraiment abordée, à savoir l'utilisation aléatoire (UUIDv4) IDs comme clés primaires va nuire à la performance du indice de clé primaire . Il va se passer si votre tableau est ordonné autour de la clé.

RDBMs généralement assurer l'unicité des clés primaires, et assurer la recherche par une clé, dans une structure appelée BTree, qui est un arbre de recherche avec un grand facteur de ramification (un binaire l'arbre de recherche a un facteur de ramification de 2). Maintenant, un ID séquentiel entier provoquerait les inserts à se produire juste un côté de l'arbre, laissant la plupart des noeuds foliaires intacts. L'ajout d'UUIDs aléatoires causera les insertions de diviser les noeuds de feuilles partout dans l'index.

de même, si les données stockées sont essentiellement temporelles, il est souvent nécessaire d'accéder aux données les plus récentes et de les rassembler contre le plus grand nombre. Avec des UUIDs aléatoires les modèles ne seront pas bénéficiez de ceci, et vont frapper plus de lignes d'index, ce qui nécessite plus des pages d'index en mémoire. Avec un IDs séquentiel si les données les plus récentes sont les plus nécessaires, les pages d'index chaud nécessiteraient moins de mémoire vive.