Identificateurs uniques et simples à l'échelle de la base de données dans SQL Server

Question

D'abord, je suis au courant cette question et la suggestion (utiliser le GUID) ne s'applique pas à ma situation.

Je veux des UIDs simples pour que mes utilisateurs puissent facilement communiquer ces informations par téléphone :

Bonjour, j'ai un problème avec la commande 1584

à l'opposé de

Bonjour, j'ai un problème avec la commande. 4daz33-d4gerz384867-8234878-14

Je veux qu'ils soient uniques (à l'échelle de la base de données) parce que j'ai plusieurs types d'"objets" différents... il y a des ID de commande, des ID de livraison et des ID de facturation et, comme il n'y a pas de relation biunivoque entre eux, je n'ai aucun moyen de deviner à quel type d'objet un ID fait référence.

Grâce aux identifiants uniques de la base de données, je peux immédiatement savoir à quel objet mon client fait référence. Mon utilisateur peut simplement saisir un ID dans un outil de recherche et je lui évite de cliquer pour affiner sa recherche.

Mon idée actuelle est d'utiliser des colonnes d'identité avec des graines différentes 1, 2, 3, etc. et une valeur d'incrément de 100.

Cela soulève toutefois quelques questions :

• Que se passera-t-il si je finis par avoir plus de 100 types d'objets ? Je pourrais utiliser 1000 ou 10000, mais quelque chose qui ne s'adapte pas bien "sent".

• Est-il possible que la graine soit "perdue" (lors d'une réplication, d'un problème de base de données, etc.)

• Plus généralement, y a-t-il d'autres problèmes dont je devrais être conscient ?

• est-il possible d'utiliser une colonne non entière (j'utilise actuellement des bigints) comme colonne d'identité, de sorte que je puisse préfixer l'ID avec quelque chose représentant le type d'objet (par exemple une colonne varchar) ?

• Est-ce que ce serait une bonne idée d'utiliser une "table maîtresse" contenant seulement une colonne d'identité, et peut-être le type d'objet, de sorte que je puisse simplement y insérer une ligne chaque fois que j'ai besoin d'une nouvelle idée. J'ai l'impression que c'est un peu exagéré, et je crains que cela ne complexifie toutes mes demandes d'insertion. De plus, je ne pourrais pas déterminer le type d'objet sans regarder la base de données.

• existe-t-il d'autres moyens astucieux de résoudre mon problème ?

Answer 1

Pourquoi ne pas utiliser les identités sur toutes les tables, mais à chaque fois que vous les présentez à l'utilisateur, ajoutez simplement un caractère unique pour le type ? par exemple, O1234 est une commande, D123213 est une livraison, etc. De cette façon, vous n'avez pas besoin de mettre au point un schéma fou...

Answer 2

Traitez-le au niveau de l'interface utilisateur - ajoutez une ou plusieurs lettres de préfixe au numéro d'identification lorsque vous le signalez aux utilisateurs. Ainsi, o472 correspondrait à une commande, b531 à une facture, et ainsi de suite. Les gens n'hésitent pas à mélanger des lettres et des chiffres lorsqu'ils donnent des "numéros" par téléphone, et ils sont plus précis qu'avec des chiffres simples.

Answer 3

Vous pourriez utiliser une colonne d'auto-incrémentation pour générer l'identifiant unique. Ensuite, une colonne calculée prend la valeur de cette colonne et la précède d'un identifiant fixe qui reflète le type d'entité. Par exemple, OR1542 et DL1542 représenteraient respectivement la commande n° 1542 et la livraison n° 1542. Votre préfixe peut être étendu autant que vous le souhaitez et le format peut être organisé de manière à distinguer les éléments ayant la même valeur d'auto-incrément, par exemple OR011542 et DL021542, avec les préfixes OR01 et DL02.

Answer 4

Je le mettrais en œuvre en définissant une table racine générique. Faute d'un meilleur nom, je l'appellerais Entity. La table Entity devrait comporter au minimum une seule colonne Identity. Vous pouvez également inclure d'autres champs communs à tous vos objets ou même des métadonnées qui vous indiquent que cette ligne est une commande, par exemple.

Chacune de vos tables Commande, Livraison... aura une référence FK renvoyant à la table Entité. Cela vous donnera une seule et unique colonne d'identification

L'utilisation des graines est, à mon avis, une mauvaise idée, qui pourrait entraîner des problèmes.

Modifier

Certains des problèmes que vous avez déjà mentionnés. Je pense aussi que c'est un problème de suivi et qu'il faut s'assurer que toutes les nouvelles entités sont correctement configurées. Imaginez qu'un développeur mette à jour le système dans deux ans.

Après avoir écrit cette réponse, j'ai réfléchi un peu plus à la raison pour laquelle vous faites cela, et je suis arrivé à la même conclusion que Matt.

Answer 5

Le projet de programmation intentionnelle de MS avait un système GUID-mot qui donnait des noms prononçables à partir d'identifiants aléatoires.