Question

Quel serait le type de données le plus efficace pour stocker un UUID / GUID dans des bases de données ne possédant pas de type de données UUID / GUID natif? 2 BIGINTs?

Et quel serait le code le plus efficace (C # préféré) pour convertir vers et depuis un GUID vers ce type?

Merci.

Était-ce utile?

La solution

Il est difficile de dire ce qui serait le plus efficace sans connaître la base de données que vous utilisez.

Mon premier réflexe serait d’utiliser une colonne binary (16) .

En ce qui concerne l'utilisation de cette valeur en C #, le type System.Guid a un constructeur qui accepte un tableau byte [] et une méthode ToByteArray () qui renvoie un tableau d'octets.

Autres conseils

D'après mon expérience, l'UUID divisé en deux entiers sera toujours plus efficace que l'utilisation d'un champ char. Différentes bases de données réagissent de différentes manières. La collation pourrait aussi faire la différence. Cela étant dit, il existe généralement des performances et des "péchés" bien plus importants. partout applications, et je ne pense pas que ce serait une chose majeure dans les deux cas pour de nombreuses applications. Vous devrez vous juger en fonction du nombre de personnes occupées par cette partie de votre application. Avez-vous besoin de l'interrogation la plus rapide possible par UUID? Est-ce que 600ns contre 400ns est un grand décalage de temps pour vous?

S'il y a beaucoup de procédures manuelles SQL avec la base de données, alors une clé contenant un UUID provenant de champs séparés est une sorte de puanteur lorsque vous devez faire une insertion et qu'il n'y a pas de valeur par défaut pour la base de données. C’est aussi un problème de caractères.

Si vous avez une couche d'abstraction de base de données, alors combiner plusieurs champs de table pour obtenir votre UUID ne devrait pas être un gros problème.

Consultation de la classe de guidage .NET , il existe deux manières d’initialiser un guid:

Guid (Int32, Int16, Int16, Octet, Octet, Octet, Octet, Octet, Octet, Octet, Octet, Octet, Octet) Guid (chaîne)

Bien qu’il soit peut-être plus efficace, en théorie, de stocker le nombre entier dans une base de données (vous pouvez utiliser le décalage de bits pour stocker réellement 4 nombres entiers de 32 bits .. mais vous devrez le calculer lors du chargement et de la sauvegarde de chaque fichier). En outre, il faudrait 4 champs dans la base de données .. J'imagine que cela finirait par être moins efficace.

Ajoutez à cela l'impossibilité de lire ceci directement dans votre base de données à des fins de débogage / test, et je dirais haut la main qu'il est préférable de stocker une chaîne. Il ne s'agit que d'un champ de 32 caractères (36 si vous incluez les tirets) et il est très facile à convertir. ToString () et new Guid (stringValue);

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top