Le stockage UUID dans la base de données HSQLDB

Question

Je souhaite stocker UUID créée en utilisant java.util.UUID dans une base de données HSQLDB.

L'option évidente est de les stocker sous forme de chaînes simplement (dans le code, ils probablement être traités comme tels), à savoir varchar (36).

Quelles autres options dois-je prendre en compte pour cela, les questions considérant comme la taille de la base de données et la vitesse de requête (dont aucun ne sont une préoccupation énorme en raison du volume des données, mais je voudrais les considérer au moins)

Answer 1

Vous avez quelques options:

• l'enregistrer comme VARCHAR (36), comme vous l'avez déjà suggéré. Cela prendra 36 octets (288 bits) de stockage par UUID, sans compter les frais généraux.
• Stocker chaque UUID dans deux colonnes BIGINT, un pour les bits les moins significatifs et un pour les bits les plus significatifs; et pour saisir chaque partie et le stocker de façon appropriée. Cela prendra 128 bits de mémoire par UUID, sans compter les frais généraux.
• chaque magasin UUID comme un objet; il stocke ce que la version sérialisée binaire de la classe UUID. Je ne sais pas combien d'espace cela prend; Je dois effectuer un test pour voir ce que la forme sérialisé par défaut d'un Java UUID est.

Les avantages et les inconvénients de chaque approche est basée sur la façon dont vous passez les UUID autour de votre application - si vous les passer autour de leurs cordes équivalents, alors l'inconvénient d'exiger le double de la capacité de stockage pour le VARCHAR (36) approche est probablement compensée par ne pas avoir à les convertir chaque fois que vous faites une requête DB ou mise à jour. Si vous les passer autour comme UUID indigènes, la méthode BIGINT est probablement assez faible surcharge.

Oh, et il est bien que vous cherchez à examiner les questions de vitesse et de l'espace de stockage, mais comme beaucoup mieux que moi l'ai dit, il est aussi bon que vous reconnaissez que ceux-ci pourraient ne pas être d'une importance cruciale étant donné la quantité de données que votre application sera le stockage et le maintien. Comme toujours, micro-optimisation pour des raisons de performance est seulement important si ne pas le faire conduit à des coûts inacceptables ou la performance. Dans le cas contraire, ces deux questions - l'espace de stockage des UUID, et le temps qu'il faut pour maintenir et les interroger dans le DB - sont raisonnablement faible importance étant donné le coût de stockage et pas cher la capacité des indices DB pour rendre votre vie beaucoup plus facile. :)

Answer 2

1. Je recommande char(36) au lieu de varchar(36). Pas sûr hsqldb, mais dans de nombreux SGBD caractère est un peu plus vite.

2. Pour les recherches, si le SGBD est intelligent, vous pouvez utiliser une valeur entière à « se rapprocher » à votre UUID.

Par exemple, ajouter une colonne int à votre table, ainsi que le char (36). Lorsque vous insérez dans votre table, insérez le uuid.hashCode () dans la colonne int. Ensuite, vos recherches peuvent être comme ça

WHERE intCol = ? and uuid = ?

Comme je l'ai dit, si hsqldb est intelligent comme MySQL ou SQL Server, il restreindre la recherche par le intCol et seulement comparer à la plupart des quelques valeurs de l'UUID. Nous utilisons cette astuce pour chercher dans les tables millions + disques par chaîne, et il est essentiellement aussi vite que d'une recherche entier.

Answer 3

HSQLDB a un type de UUID intégré. Utilisez cette

CREATE TABLE t (
  id UUID PRIMARY KEY
);

Answer 4

Utilisation BINARY (16) est une autre possibilité. Moins d'espace de stockage que les types de caractères. Utilisez CREATE UUID TYPE .. ou CREATE DOMAIN UUID .. comme suggéré ci-dessus.

Answer 5

Je pense que la meilleure chose à faire serait de créer votre propre domaine créant ainsi votre propre UUID « type » (pas vraiment un type, mais presque).

Vous devriez envisager également la réponse à cette question (surtout si vous prévoyez de l'utiliser au lieu d'une clé primaire « normale »)

INT, BIGINT ou UUID / GUID dans HSQLDB?

HSQLDB: Création de domaine et manipulation