GUID SQL Server (à partir d'Active Directory) vs Int

Question

Nous avons migré de nombreuses données de notre ancien système de commande.Ce système stockait les initiales des utilisateurs dans notre tableau « Commandes » pour chaque commande qu'ils créaient.Maintenant que nous avons une vue qui regarde Active Directory, je voudrais mettre à jour ces initiales avec l'objectguid Active Directory (ou quelque chose qui fait référence au GUID).Cela nous permettrait de modifier les initiales des utilisateurs dans Active Directory sans avoir à nous soucier de la mise à jour des enregistrements de la table « Commandes ».

J'ai lu que les performances des index sont médiocres lors de l'utilisation de guids et d'ints.Une façon de résoudre ce problème est d'avoir une table qui mappe les guids aux ints, puis de stocker la valeur int dans notre table des commandes.Serait-ce une bonne idée ?Des pensées?

Answer 1

Je suppose qu'un UTILISATEUR L'entité existe déjà dans la conception de votre base de données, mais si ce n'est pas le cas, je pense que votre solution l'exigera.

Donc en supposant que UTILISATEUR entité existe, comme vous l'avez décrit, vous pouvez placer le UserID(int) sur le ORDRES tableau, reliant ainsi tous les UTILISATEUR détails à un COMMANDE, plutôt que de simples initiales (Remarque :Les initiales ne devraient sans doute pas être stockées sur le COMMANDE table mais plutôt le UTILISATEUR ou USER_DETAILS tableau, même si ce n’est pas l’objet de cette discussion).

Vous pouvez ensuite ajouter la colonne GUID à la table USER.Je ne pense pas qu'une table de recherche distincte soit nécessaire.

Cela a du sens ?

Answer 2

Les performances des index sur les GUID ne sont en général pas différentes de celles des autres index sur un champ de 16 octets.Là où les GUID sont mortels pour les performances, c'est lorsque vous les utilisez comme clé de regroupement sur une table SQL Server.

Le tableau SQL Server est la clé clusterisée et est physiquement ordonnée par cette clé.Étant donné que les GUID sont par nature totalement aléatoires, cela conduit très rapidement à une fragmentation massive des index, et nécessite donc a) une alimentation, des soins et une réorganisation constants, mais b) souffre toujours même si vous vous réorganisez chaque nuit.Donc, vraiment, la meilleure pratique serait d'éviter les GUID (même les nouveaux GUID "séquentiels") pour votre clé de clustering.

Pour plus d'informations générales et d'excellents articles expliquant pourquoi les GUID créent de très mauvaises clés clusterisées, consultez le blog de la "Reine de l'indexation", Kimberly Tripp :

• GUID comme clé primaire
• Le débat sur les index clusterisés se poursuit....
• Le débat sur les index clusterisés... encore une fois !

Sa perspicacité est des plus précieuses : lisez-la, intériorisez-la, suivez-la !Vous ne le regretterez pas.

Marc