Utilisation d'un GUID et d'un entier auto-incrémenté

Question

J'ai étudié l'utilisation des GUID comme clés primaires dans les bases de données. Jusqu'à présent, les avantages semblent l'emporter sur les inconvénients. Cependant, je vois un point où les GUID peuvent ne pas être ce que je veux.

Dans mon application, les utilisateurs doivent pouvoir identifier les objets en fonction d'un ID convivial. Ainsi, par exemple, s'ils veulent obtenir un produit spécifique sans entrer le nom complet, ils peuvent utiliser l'ID du produit. Les GUID ne sont pas faciles à retenir pour quelque chose comme ça.

La solution à laquelle j'ai pensé est d'utiliser à la fois un GUID et un entier auto-incrémenté. Le GUID serait la clé primaire de la ligne, tandis que l'entier auto-incrémenté serait un index utilisé par les fonctions de filtrage de l'application. Cependant, toutes les instructions SQL SELECT, UPDATE, DELETE utiliseront le GUID. La principale raison pour laquelle je souhaite utiliser les GUID est d'éviter les conflits lors de la fusion de deux bases de données. Si la base de données # 1 et la base de données # 2 ont toutes deux un produit # 2, le script de l'importateur devrait changer l'ID et toutes les clés étrangères qui s'y réfèrent. Avec les GUID, je n'ai qu'à modifier l'ID convivial dans la table elle-même, alors que les clés étrangères utiliseraient le GUID unique à chaque enregistrement importé et fonctionneraient donc sans modification. Donc, ma question est la suivante: existe-t-il des problèmes majeurs (outre la taille du champ GUID et la fragmentation facile des pages) avec un index d'entier auto-incrémenté et une clé primaire GUID?

Answer 1

J'ai toujours tendance à utiliser des clés primaires de substitution dans ma base de données. En d'autres termes: ces clés primaires n'ont aucune signification réelle dans le domaine de problème et, par conséquent, ces clés primaires ne sont jamais exposées aux utilisateurs. (Si cette clé primaire de substitution est de type GUID ou une identité, cela m'est égal, cela dépend des exigences). Si vous dites que les utilisateurs devraient être en mesure d'identifier les objets sur la base d'un identifiant convivial, je pense que cet identifiant convivial est une valeur qui appartient à votre «domaine de problème». Cela signifie que cet ID doit en effet être un attribut de votre table, mais qu'il ne doit pas être utilisé comme clé primaire dans votre table. Cela vous permet également de modifier facilement la valeur d'un tel identifiant convivial (si cela est nécessaire), sans que vous n'ayez à vous préoccuper de la modification des clés étrangères associées.

Answer 2

En MySQL, vous devez définir votre ID numérique en tant que PRIMARY KEY, comme AUTO_INCREMENT peut être que le PRIMARY KEY, ce qui signifie qu'il devrait également être NOT NULL.

Vous pouvez toujours définir un UNIQUE INDEX sur votre colonne GUID et de l'utiliser partout, mais une table InnoDB sera regroupée sur le id numérique, non pas sur le GUID.

Answer 3

Il ya une école de pensée là-bas qui dit que vous ne devriez jamais exposer vos ID de substitution au monde extérieur. Donc, ils diraient que si vous voulez une identification d'entreprise, vous devriez utiliser quelque chose d'autre pour cela.

This Wikipedia article, par exemple, dit ceci:

Dissociation

Les valeurs des clés de substitution générées - car ils sont générés et arbitraires - ont aucun lien avec le sens du monde réel de la données tenues dans une rangée. Lors de l'inspection d'une autre ligne contenant une référence de clé étrangère à une clé de substitution, il n'est pas possible de déterminer la signification de celui-ci en maintenant référence simplement en regardant les données dans la ligne elle-même. Une couche est ajoutée à cette indirection pour chaque jointure de clé étrangère que vous devez parcourir en essayant de faire le sens d'un élément de données. Cela peut également rendre l'audit plus difficile, car les données incorrectes ne sont pas évidentes lors de l'inspection .

Les clés de substitution ne sont pas naturelles non plus pour les données exportées et partagées. Une difficulté particulière est que deux cas d'un schéma peut contenir des enregistrements ce qui signifie logiquement la même chose (c'est - ce sont les mêmes dans un sens des affaires ), mais qui ont une clé différente en raison de l'histoire de comment les clés ont été attribuées. Une approche de traiter ce problème est de adopter la règle selon laquelle les clés de substitution sont jamais exportées ou importées: ils sont jamais exposés en dehors de la base de données , sauf que les données transitoires (plus évidemment, dans l'exécution des applications qui ont un « live "connexion à la base de données ).

Answer 4

« Pourquoi « les utilisateurs devraient être en mesure d'identifier des objets à partir d'un ID convivial »?

À mon avis, vos utilisateurs doivent itentify enregistrements à l'aide des codes.

Disons que votre base de données contient des produits (comme vous l'avez mentionné dans Question) Ne serait-il pas mieux s'ils avaient des codes pour représenter les produits, que les utilisateurs pourraient entrer

Disons que vous avez des tables et des chaises, en tant qu'utilisateur, je préférerais en utilisant tbl et chr que 1 et 2 pour identifier de quoi je parle

Answer 5

Pour être plus précis sur votre question, oui il y a d'autres problèmes avec l'utilisation GUIDs comme clés primaires dans les bases de données:

Le problème est pas tant à l'aide d'un GUID comme clé primaire, son en utilisant un GUID non séquentiel en tant qu'index en cluster pour une table. Le point à retenir consiste ici soit à utiliser d'autres champs comme index clusterisé, soit à utiliser un GUID séquentiel pour éviter cette fragmentation.