Quel est le type de colonne UUID le plus efficace
Pour stocker un UUID 128 bits, il existe plusieurs options de stockage:
- une colonne d'octet [16]
- deux colonnes bigint/long (64 bits)
- une colonne CHAR (36) - 32 chiffres hexadécimaux + 4 tirets.
- une colonne spécifique à la base de données UUID, si db la prend en charge
Du point de vue de l'indexation, lesquels sont les plus efficaces? Si la base de données ne prend pas en charge un type d'uuid dédié, lesquels parmi 1, 2, 3 sont les meilleurs candidats?
Un type uuid dédié est votre meilleur pari pour PostgreSQL. Difficile à dire avec d'autres bases de données - il n'est pas impossible pour quelqu'un d'implémenter un type uuid qui est stocké moins efficacement qu'un type d'octet simple.
Encore une fois dans PostgreSQL, bytea serait un moyen raisonnable de stocker les UUID si vous n'aviez pas le type uuid. Pour les autres bases de données, cela dépend de la façon dont elles stockent les données binaires.
Dans la mesure du possible, j'évite fortement d'utiliser hex-with-dashes. C'est beaucoup moins efficace pour comparer, trier et stocker.
Donc vraiment, "pas (2) ou (3)". Déjà. Utilisez (4) lorsque cela est pris en charge, (1) sinon.
Dans l'ordre de préférence: 4,1,2,3 N'utilisez pas les UUID comme clé de clustering si vous utilisez SQL Server car, non seulement il se fragmentera mal, la clé de clustering est utilisée dans tous les index non clusterisés et vous ajouterez ces octets à chaque ligne d'index. La fragmentation peut être atténuée en utilisant NEWSEQUENTIALID mais préférez généralement une identité bingint pour votre clé de clustering à un GUID pour éviter les ballonnements dans d'autres index.
La différence entre le choix de 1 sur 2 dépendra de l'efficacité avec laquelle la base de données gère deux colonnes de types de base sur un tableau fixe à une seule colonne. Il devrait être assez facile de tester avec des données factices. Regardez la vitesse de vos requêtes ainsi que la taille des index et des données. Petit + rapide est le meilleur!
Il faudrait supposer que tout type de données pris en charge nativement serait mieux optimisé dans le produit que tout ce qui pourrait être assemblé en tant que client de ce produit. Après cela, tout ce qui a le plus petit nombre d'octets vous permet donc d'obtenir le maximum de lignes par page.