Quand êtes-vous vraiment obligé d'utiliser l'UUID dans le cadre de la conception?


123

Je ne vois pas vraiment l'intérêt de l' UUID . Je sais que la probabilité d'une collision est effectivement nulle , mais effectivement nulle n'est même pas presque impossible.

Quelqu'un peut-il donner un exemple où vous n'avez pas d'autre choix que d'utiliser UUID? De toutes les utilisations que j'ai vues, je peux voir une conception alternative sans UUID. Bien sûr, la conception peut être un peu plus compliquée, mais au moins elle n'a pas de probabilité d'échec non nulle.

UUID sent les variables globales pour moi. Il existe de nombreuses façons dont les variables globales simplifient la conception, mais sa conception est simplement paresseuse.


23
Tout a une chance d'échec non nulle. Je me concentrerais sur des problèmes beaucoup plus susceptibles de se produire (c'est-à-dire presque tout ce à quoi vous pouvez penser) que la collision des UUID
DanSingerman

16
En fait, «effectivement nul» est presque impossible.
mqp

21
Non, c'est en fait infiniment loin d'être impossible
Pyrolistique

32
@Pyrolistical lorsque vous commencez à lancer des mots comme «infini», vous avez quitté le monde du développement logiciel. La théorie de l'informatique est une discussion entièrement différente de celle de l'écriture de vrais logiciels.
Rex M

2
Je vais fermer principalement parce que le sha1 de git m'a convaincu de la bonté d'un hachage
Pyrolistical

Réponses:


617

J'ai écrit le générateur / analyseur UUID pour Ruby, donc je me considère comme raisonnablement bien informé sur le sujet. Il existe quatre versions majeures d'UUID:

Les UUID de la version 4 ne sont essentiellement que 16 octets d'aléa tirés d'un générateur de nombres aléatoires cryptographiquement sécurisé, avec un peu de bit-twiddling pour identifier la version et la variante de l'UUID. Celles-ci sont extrêmement peu susceptibles d'entrer en collision, mais cela pourrait arriver si un PRNG est utilisé ou si vous avez vraiment, vraiment, vraiment, vraiment, vraiment de la malchance.

Les UUID des versions 5 et 3 utilisent respectivement les fonctions de hachage SHA1 et MD5 pour combiner un espace de noms avec une partie de données déjà uniques afin de générer un UUID. Cela vous permettra, par exemple, de produire un UUID à partir d'une URL. Les collisions ici ne sont possibles que si la fonction de hachage sous-jacente a également une collision.

Les UUID de la version 1 sont les plus courants. Ils utilisent l'adresse MAC de la carte réseau (qui, à moins d'être usurpée, devrait être unique), plus un horodatage, plus le bit-twiddling habituel pour générer l'UUID. Dans le cas d'une machine qui n'a pas d'adresse MAC, les 6 octets de nœud sont générés avec un générateur de nombres aléatoires cryptographiquement sécurisé. Si deux UUID sont générés en séquence suffisamment rapidement pour que l'horodatage corresponde à l'UUID précédent, l'horodatage est incrémenté de 1. Les collisions ne doivent pas se produire à moins que l'une des situations suivantes ne se produise: l'adresse MAC est usurpée; Une machine exécutant deux applications générant des UUID différentes produit des UUID exactement au même moment; Deux machines sans carte réseau ou sans accès de niveau utilisateur à l'adresse MAC reçoivent la même séquence de nœuds aléatoires et génèrent des UUID exactement au même moment;

En réalité, aucun de ces événements ne se produit par accident dans l'espace d'identification d'une seule application. À moins que vous n'acceptiez des identifiants sur, par exemple, une échelle Internet ou dans un environnement non fiable où des individus malveillants pourraient être en mesure de faire quelque chose de mal en cas de collision d'identifiants, ce n'est tout simplement pas quelque chose dont vous devriez vous inquiéter. Il est essentiel de comprendre que si vous générez le même UUID version 4 que moi, dans la plupart des cas, cela n'a pas d'importance. J'ai généré l'ID dans un espace d'identification complètement différent du vôtre. Mon application ne sera jamais au courant de la collision, donc la collision n'a pas d'importance. Franchement, dans un seul espace applicatif sans acteurs malveillants, l'extinction de toute vie sur terre se produira bien avant que vous n'ayez une collision, même sur un UUID version 4, même si vous '

De plus, 2 ^ 64 * 16 équivaut à 256 exaoctets. Comme dans, vous auriez besoin de stocker 256 exaoctets d'ID avant d'avoir 50% de chances de collision d'ID dans un seul espace d'application.


8
C'est de loin la meilleure explication. Je ne sais pas pourquoi ce n'est pas voté au sommet. Félicitations à vous Sporkmonger.
Brad Barker

1
@Chamnap J'ai écrit UUIDTools. Les UUID peuvent être convertis en un entier ou sous leur forme d'octet brut, et seraient considérablement plus petits en tant que binaire.
Bob Aman

1
@Chamnap uuid.rawvous donnera la chaîne d'octets. La hashméthode ne vous est pas utile. Il est utilisé pour les tables de hachage et les opérations de comparaison en interne dans Ruby. Toutes les méthodes de conversion vers et à partir de diverses représentations UUID sont définies comme des méthodes de classe et doivent être préfixées par "parse".
Bob Aman du

3
@BobAman en 1990, j'ai eu 12 collisions d'UUID sur un système Aegis, ce qui s'est avéré être un FPU défectueux, mais j'ai pensé que je vous ferais savoir que cela peut arriver (cela ne s'est pas produit à part cela au cours des 30 dernières années de programmation) . Belle explication, trop btw, c'est maintenant mon post de référence UUID de facto à donner aux gens :)
GMasucci

2
@kqr Vous avez tout à fait raison de dire que c'est le problème de l'anniversaire, cependant pour un code n bits, le problème du paradoxe de l'anniversaire se réduit à 2 ^ (n / 2), qui dans ce cas est de 2 ^ 64, comme indiqué dans ma réponse .
Bob Aman

69

La chose que les UUID vous achètent et qui est très difficile à faire autrement est d'obtenir un identifiant unique sans avoir à consulter ou à se coordonner avec une autorité centrale . Le problème général de pouvoir obtenir une telle chose sans une sorte d'infrastructure gérée est le problème que les UUID résolvent.

J'ai lu que, selon le paradoxe de l'anniversaire, la probabilité qu'une collision d'UUID se produise est de 50% une fois que 2 ^ 64 UUID ont été générés. Maintenant, 2 ^ 64 est un nombre assez important, mais une probabilité de collision de 50% semble beaucoup trop risquée (par exemple, combien d'UUID doivent exister avant qu'il y ait une chance de collision de 5% - même cela semble être une probabilité trop grande) .

Le problème avec cette analyse est double:

  1. Les UUID ne sont pas entièrement aléatoires - certains composants principaux de l'UUID sont basés sur l'heure et / ou l'emplacement. Ainsi, pour avoir une chance réelle de collision, les UUID en collision doivent être générés exactement au même moment à partir de différents générateurs d'UUID. Je dirais que s'il y a une chance raisonnable que plusieurs UUID puissent être générés en même temps, il y a suffisamment d'autres saletés (y compris des informations de localisation ou des bits aléatoires) pour rendre presque impossible la possibilité d'une collision entre ce très petit ensemble d'UUID. .

  2. à proprement parler, les UUID doivent être uniques parmi l'ensemble des autres UUID auxquels ils peuvent être comparés. Si vous générez un UUID à utiliser comme clé de base de données, peu importe si ailleurs dans un univers alternatif maléfique, le même UUID est utilisé pour identifier une interface COM. Tout comme cela ne causera aucune confusion s'il y a quelqu'un (ou quelque chose) d'autre nommé "Michael Burr" sur Alpha-Centauri.


1
Exemple concret? UUID COM / DCE - il n'y a pas d'autorité pour les attribuer, et personne ne voulait en prendre la responsabilité et / ou personne ne voulait qu'il y ait une autorité. Bases de données distribuées qui n'ont pas de liens fiables et pas de maître.
Michael Burr

3
Exemple plus concret - une application bancaire. Il est installé plusieurs centres de données, un pour chaque pays, chaque centre de données ayant une base de données. Les multiples installations sont là pour obéir à des réglementations différentes. Il ne peut y avoir qu'un seul enregistrement client dans l'ensemble complet pour chaque client .....
Vineet Reynolds

(Suite du commentaire précédent) Vous devez disposer d'un serveur central pour générer l'ID client à des fins de reporting et de suivi global (sur toutes les installations) ou faire en sorte que les installations individuelles génèrent des UUID pour servir d'ID client (évidemment, les UUID ne peuvent pas être utilisés comme dans dans les rapports).
Vineet Reynolds

Au moment où vous avez 50% de chances de duplication, vous vous noyez déjà. Quelqu'un indique le volume requis pour atteindre 0,0000001% de chance. Plusieurs bases de données auto-incrémentées commençant de 1 à n et augmentant de n à chaque fois résolvent efficacement le même problème.
Gordon

2
Les chances d'obtenir un double sont FAR, BEAUCOUP inférieures aux chances que l'autorité centrale échoue d'une manière critique pour la mission
std''OrgnlDave

33

Tout a une chance d'échec non nulle. Je me concentrerais sur des problèmes beaucoup plus susceptibles de se produire (c'est-à-dire presque tout ce à quoi vous pouvez penser) que la collision d'UUID


Ajouté comme réponse à la demande de
Pyrolistical

16

Un accent sur «raisonnablement» ou, comme vous le dites, «effectivement»: assez bien est la façon dont le monde réel fonctionne. La quantité de travail informatique nécessaire pour combler cet écart entre «pratiquement unique» et «vraiment unique» est énorme. L'unicité est une courbe avec des rendements décroissants. À un moment donné sur cette courbe, il y a une ligne entre où «assez unique» est encore abordable, puis nous courbons TRÈS brusquement. Le coût d'ajouter plus d'unicité devient assez élevé. L'unicité infinie a un coût infini.

UUID / GUID est, relativement parlant, un moyen simple et rapide de générer un ID qui peut être raisonnablement supposé être universellement unique. Ceci est très important dans de nombreux systèmes qui ont besoin d'intégrer des données provenant de systèmes auparavant non connectés. Par exemple: si vous disposez d'un système de gestion de contenu qui fonctionne sur deux plates-formes différentes, mais que vous devez à un moment donné importer le contenu d'un système dans l'autre. Vous ne voulez pas que les ID changent, donc vos références entre les données du système A restent intactes, mais vous ne voulez pas de collisions avec les données créées dans le système B. Un UUID résout ce problème.


Solution. Ne soyez pas paresseux et mettez à jour les références. Fais-le bien.
Pyrolistique

8
Cela n'a rien à voir avec la paresse - si la politique est qu'un ID pour un élément est considéré comme permanent et immuable, alors l'ID ne change pas. Vous voulez donc que les identifiants soient uniques dès le départ, et vous voulez le faire sans exiger que tous les systèmes soient connectés d'une manière ou d'une autre dès le début.
Michael Burr

Vous avez alors besoin de contexte. Si vous avez deux groupes d'identifiants uniques qui peuvent entrer en conflit, vous avez besoin d'un niveau élevé de contexte pour les séparer
Pyrolistique

23
Ou, vous pouvez simplement construire le système pour utiliser les UUID et l'expédier, le vendre, gagner un million de dollars et ne jamais entendre une seule plainte selon laquelle deux ID se sont heurtés parce que cela n'arrivera pas.
Rex M

16

Il n'est jamais absolument nécessaire de créer un UUID. Il est cependant pratique d'avoir une norme où les utilisateurs hors ligne peuvent chacun générer une clé pour quelque chose avec une très faible probabilité de collision.

Cela peut aider à la résolution de réplication de base de données, etc.

Il serait facile pour les utilisateurs en ligne de générer des clés uniques pour quelque chose sans la surcharge ou la possibilité de collision, mais ce n'est pas à cela que servent les UUID.

Quoi qu'il en soit, un mot sur la probabilité de collision, tiré de Wikipedia:

Pour mettre ces chiffres en perspective, le risque annuel d'être touché par une météorite est estimé à une chance sur 17 milliards, ce qui équivaut à la probabilité de créer quelques dizaines de billions d'UUID en un an et d'avoir un double. En d'autres termes, seulement après avoir généré 1 milliard d'UUID par seconde pendant les 100 prochaines années, la probabilité de créer un seul duplicata serait d'environ 50%.


4
Simple, ne laissez pas les utilisateurs hors ligne générer des clés. Faites attribuer les clés temporaires jusqu'à ce que le système se connecte afin que les vraies clés puissent être générées.
Pyrolistique

C'est une réponse très utile à mon avis ... allait offrir moi-même une sorte d'analogie avec la probabilité, car il semblait que le PO ne comprenait pas tout à fait sa signification, mais vous semblez l'avoir fait.
Noldorin

Je comprends bien que la probabilité est effectivement nulle. Pour moi, l'utilisation de l'UUID est un design paresseux, et je voulais juste voir si vous pouviez toujours l'éviter
Pyrolistique

C'est assez juste, tant que vous voyez que la faible probabilité doit même être prise en compte dans les circonstances les plus extrêmes, comme je suppose que vous le faites maintenant.
Noldorin

13

Un exemple classique est celui de la réplication entre deux bases de données.

DB (A) insère un enregistrement avec l'ID int 10 et en même temps DB (B) crée un enregistrement avec l'ID 10. Il s'agit d'une collision.

Avec les UUID, cela ne se produira pas car ils ne correspondent pas. (presque certainement)


1
Ok, alors faites en sorte que DB A utilise des ID pairs et que DB B utilise des ID impairs. Terminé, pas d'UUID.
Pyrolistique

2
Avec trois DB, utilisez 3 multiples LOL
Jhonny D. Cano -Leftware-

20
Si vous utilisez les multiples 2/3 / quels que soient les multiples, que se passe-t-il lorsque vous ajoutez un nouveau serveur dans le mix plus tard? Vous devez coordonner un commutateur afin que vous utilisiez n + 1 multiples sur le nouveau serveur, et déplacer tous les anciens serveurs vers le nouvel algorithme, et vous devez tout arrêter pendant que vous faites cela pour éviter les collisions pendant le commutateur d'algorithme. Ou ... vous pouvez simplement utiliser des UUID comme TOUT LE MONDE.
Bob Aman

3
C'est encore pire que cela, car comment différencieriez-vous les multiples de 2 et les multiples de 4? Ou des multiples de 3 contre des multiples de 6? En fait, vous devrez vous en tenir à des multiples de nombres premiers. Blech! Utilisez simplement UUID, cela fonctionne. Microsoft, Apple et d'innombrables autres comptent sur eux et leur font confiance.
sidewinderguy

2
@sidewinderguy, dans GUID nous avons confiance! :)
Ron Klein

13

Il existe également une probabilité non nulle que chaque particule de votre corps traverse simultanément la chaise sur laquelle vous êtes assis et vous vous retrouvez soudainement assis sur le sol.

Vous en inquiétez-vous?


7
Bien sûr que non, ce n'est pas quelque chose que je peux contrôler, mais des designs que je peux.
Pyrolistique

4
@Pyrolistical Est- ce vraiment, je veux dire VRAIMENT la raison pour laquelle vous ne vous inquiétez pas à ce sujet? Alors vous êtes assez étrange. Et de plus, vous n'avez pas raison. Vous pouvez le contrôler. Si vous gagnez quelques kilos, vous diminuez considérablement la probabilité d'un tel événement. Pensez-vous donc que vous devriez prendre du poids? :-)
Veky

8

J'ai un schéma pour éviter les UUID. Configurez un serveur quelque part et ayez-le pour que chaque fois qu'un logiciel souhaite un identifiant unique universel, il contacte ce serveur et il en distribue un. Facile!

Sauf qu'il y a de vrais problèmes pratiques avec cela, même si on ignore carrément la méchanceté. En particulier, ce serveur peut tomber en panne ou devenir inaccessible depuis une partie d'Internet. Faire face à une panne de serveur nécessite une réplication, et c'est très difficile à faire correctement (voir la littérature sur l'algorithme Paxos pour savoir pourquoi la création de consensus est délicate) et est également assez lente. De plus, si tous les serveurs sont inaccessibles depuis une partie particulière du réseau, aucun des clients connectés à ce sous-réseau ne pourra rien faire car ils attendront tous de nouveaux identifiants.

Alors ... utilisez un simple algorithme probabiliste pour les générer qui ne risquent pas d'échouer pendant la durée de vie de la Terre, ou (financez et) construisez une infrastructure majeure qui va être un déploiement PITA et qui aura des échecs fréquents. Je sais lequel je choisirais.


2
En fait, le but de l'invention des UUID était d'éviter votre approche. Si vous recherchez l'historique des UUID, vous verrez qu'il provient des premières expériences de création de réseaux d'ordinateurs sophistiqués et significatifs. Ils savaient que les réseaux sont intrinsèquement peu fiables et compliqués. Les UUID répondaient à la question de savoir comment coordonner les données entre les ordinateurs lorsque vous saviez qu'ils ne pouvaient pas être en communication constante.
Basil Bourque

7
@BasilBourque J'utilisais le sarcasme dans ce premier paragraphe, au cas où ce ne serait pas évident.
Donal Fellows

5

Je ne comprends pas tout le monde sur la probabilité d'une collision. Je me fiche de la collision. Je me soucie de la performance cependant.

https://dba.stackexchange.com/a/119129/33649

Les UUID sont un désastre de performances pour les très grandes tables. (200 000 lignes ne sont pas "très volumineuses".)

Votre # 3 est vraiment mauvais quand le CHARCTER SET est utf8 - CHAR (36) occupe 108 octets!

Les UUID (GUID) sont très "aléatoires". Les utiliser comme clé UNIQUE ou PRIMAIRE sur de grandes tables est très inefficace. Ceci est dû au fait que vous devez sauter autour de la table / index chaque fois que vous INSÉRER un nouvel UUID ou SELECT par UUID. Lorsque la table / index est trop volumineux pour tenir dans le cache (voir innodb_buffer_pool_size, qui doit être plus petit que la RAM, généralement 70%), l'UUID `` suivant '' peut ne pas être mis en cache, d'où une frappe lente sur le disque. Lorsque la table / index est 20 fois plus grand que le cache, seuls 1 / 20e (5%) des hits sont mis en cache - vous êtes lié aux E / S.

Donc, n'utilisez pas d'UUID sauf si

vous avez de «petites» tables, ou vous en avez vraiment besoin parce que vous générez des identifiants uniques à partir d'endroits différents (et que vous n'avez pas trouvé d'autre moyen de le faire). En savoir plus sur les UUID: http://mysql.rjweb.org/doc.php/uuid (Il comprend des fonctions de conversion entre les UUID standard de 36 caractères et BINARY (16).)

Avoir à la fois un AUTO_INCREMENT UNIQUE et un UUID UNIQUE dans la même table est un gaspillage.

Lorsqu'un INSERT se produit, toutes les clés uniques / primaires doivent être vérifiées pour les doublons. L'une ou l'autre clé unique est suffisante pour l'exigence d'InnoDB d'avoir une CLÉ PRIMAIRE. BINARY (16) (16 octets) est quelque peu volumineux (un argument contre en faire le PK), mais pas si mal. L'encombrement est important lorsque vous avez des clés secondaires. InnoDB cloue silencieusement le PK à l'extrémité de chaque clé secondaire. La principale leçon ici est de minimiser le nombre de clés secondaires, en particulier pour les très grandes tables. À titre de comparaison: INT UNSIGNED est de 4 octets avec une plage de 0 à 4 milliards. BIGINT est de 8 octets.


4

Si vous regardez simplement les alternatives, par exemple pour une application de base de données simple, pour avoir à interroger la base de données à chaque fois avant de créer un nouvel objet, vous constaterez bientôt que l'utilisation de l'UUID peut réduire efficacement la complexité de votre système. Accordé - si vous utilisez des clés int, elles sont 32 bits, qui seront stockées dans un quart de l'UUID 128 bits. Certes, les algorithmes de génération d'UUID prennent plus de puissance de calcul que la simple incrémentation d'un nombre. Mais - qui s'en soucie? Les frais généraux liés à la gestion d'une «autorité» pour attribuer des numéros par ailleurs uniques l'emportent facilement sur des ordres de grandeur, en fonction de l'espace d'identification d'unicité prévu.


3

Sur UUID == design paresseux

Je ne suis pas d'accord sur le choix de vos combats. Si un UUID dupliqué est statistiquement impossible et que le calcul est prouvé, pourquoi s'inquiéter? Passer du temps à concevoir autour de votre petit système de génération N UUID n'est pas pratique, il y a toujours une douzaine d'autres façons d'améliorer votre système.


1

Lors de mon dernier travail, nous recevions des objets de tiers qui étaient uniquement identifiés avec UUID. J'ai mis dans une table de recherche UUID-> long entier et utilisé un entier long comme clé primaire car c'était beaucoup plus rapide de cette façon.


Oui, bien sûr, un tiers vous obligeant à utiliser l'UUID est un autre problème que je ne veux pas aborder. En supposant que vous ayez le contrôle d'utiliser UUID ou non.
Pyrolistique

Eh bien, un "entier long" (128 bits) est en fait ce qu'est un UUID. Il est simplement montré comme une chaîne pour la consommation humaine. Parfois, il peut être transmis de cette façon, mais pour le stockage et l'indexation, il sera certainement plus rapide sous forme d'entier que vous l'avez trouvé.
Nicole

1

En utilisant l'algorithme de la version 1, il semble qu'il soit impossible de collision sous la contrainte que moins de 10 UUID par milliseconde sont générés à partir de la même adresse MAC

Conceptuellement, le schéma de génération original (version 1) des UUID consistait à concaténer la version UUID avec l'adresse MAC de l'ordinateur qui génère l'UUID, et avec le nombre d'intervalles de 100 nanosecondes depuis l'adoption du calendrier grégorien en Occident. . En pratique, l'algorithme proprement dit est plus compliqué. Ce schéma a été critiqué en ce qu'il n'est pas suffisamment «opaque»; il révèle à la fois l'identité de l'ordinateur qui a généré l'UUID et l'heure à laquelle il l'a fait.

Quelqu'un me corrige si j'ai mal interprété comment cela fonctionne


Il existe de nombreuses versions et de nombreux systèmes logiciels (Java par exemple) ne peuvent pas utiliser la version 1 car il ne dispose pas d'un moyen Java pur pour accéder à l'adresse mac.
Pyrolistique

Concernant l'incapacité de Java à obtenir l'adresse MAC: pas tout à fait vrai. Il existe des solutions de contournement pour cela. Vous pouvez définir manuellement l'adresse MAC utilisée par le générateur via un fichier de configuration. Vous pouvez également appeler ifconfig et analyser la sortie. Le générateur Ruby UUID que j'ai écrit utilise les deux approches.
Bob Aman

De plus, comme mentionné dans ma réponse, si vous ne pouvez pas obtenir une adresse MAC pour un UUID de version 1, vous utilisez à la place 6 octets aléatoires, conformément à la section 4.5 de la RFC 4122. Donc, même si vous ne souhaitez utiliser aucun des les deux solutions de contournement pour Java, vous pouvez toujours générer un UUID version 1 valide.
Bob Aman

Les GUID MS ne sont que des nombres aléatoires. Ils n'ont plus de partie MAC, car cela a permis de rétroconcevoir l'adresse MAC du serveur (qui s'est avérée très dangereuse).
Stefan Steiger

1

À ceux qui disent que les UUID sont de mauvaise conception car ils pourraient (à une probabilité ridiculement faible) entrer en collision, alors que vos clés générées par DB ne le seront pas ... vous connaissez le risque d'erreur humaine provoquant une collision sur vos clés générées par DB à cause de certains -Le besoin prévisible est de loin plus élevé que le risque de collision UUID4. Nous savons que si la base de données est recréée, elle redémarrera à nouveau les identifiants à 1, et combien d'entre nous ont dû recréer une table alors que nous étions sûrs de ne jamais en avoir besoin? Je mettrais mon argent sur la sécurité UUID quand les choses commencent à mal tourner avec des inconnus inconnus n'importe quel jour.


0

Mis à part les cas où vous devez utiliser l'API de quelqu'un d'autre qui nécessite un UUID, il y a bien sûr toujours une autre solution. Mais ces alternatives résoudront-elles tous les problèmes que posent les UUID? Finirez-vous par ajouter plus de couches de hacks, chacun pour résoudre un problème différent, alors que vous auriez pu les résoudre tous en même temps?

Oui, il est théoriquement possible que les UUID entrent en collision. Comme d'autres l'ont noté, c'est ridiculement improbable au point que cela ne vaut tout simplement pas la peine d'être considéré. Cela n'est jamais arrivé à ce jour et ne le sera probablement jamais. Oublie ça.

Le moyen le plus "évident" d'éviter les collisions est de laisser un serveur unique générer des identifiants uniques sur chaque insert, ce qui crée évidemment de sérieux problèmes de performances et ne résout pas du tout le problème de génération hors ligne. Oups.

L'autre solution "évidente" est une autorité centrale qui distribue à l'avance des blocs de numéros uniques, ce qui est essentiellement ce que fait UUID V1 en utilisant l'adresse MAC de la machine génératrice (via l'IEEE OUI). Mais les adresses MAC dupliquées se produisent parce que chaque autorité centrale finit par se foutre, donc en pratique, c'est beaucoup plus probable qu'une collision UUID V4. Oups.

Le meilleur argument contre l'utilisation des UUID est qu'ils sont "trop ​​gros", mais un schéma (significativement) plus petit échouera inévitablement à résoudre les problèmes les plus intéressants; La taille des UUID est un effet secondaire inhérent de leur utilité pour résoudre ces problèmes.

Il est possible que votre problème ne soit pas assez important pour avoir besoin de ce qu'offrent les UUID, et dans ce cas, n'hésitez pas à utiliser autre chose. Mais si votre problème se développe de manière inattendue (et la plupart le font), vous finirez par changer plus tard - et vous vous en voudrez de ne pas les utiliser en premier lieu. Pourquoi concevoir pour l'échec alors qu'il est tout aussi simple de concevoir pour réussir?


-10

Les UUID incarnent toutes les mauvaises pratiques de codage associées aux variables globales, pire encore, car ce sont des variables super globales qui peuvent être réparties sur différents éléments du kit.

Récemment, j'ai rencontré un tel problème avec le remplacement d'une imprimante par un modèle de remplacement exact et a constaté qu'aucun logiciel client ne fonctionnait.


2
Heureux que nous vivions dans une société qui se concentre toujours sur des faits plutôt que sur des opinions aléatoires, sinon nous serions tous au chômage. :)
Makarand
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.