Memorizzazione UUID nel database HSQLDB

Question

Vorrei memorizzare UUID creata usando java.util.UUID in un database HSQLDB.

L'opzione più ovvia è quella memorizzarli semplicemente come stringhe (nel codice saranno probabilmente solo essere trattati come tali), vale a dire varchar (36).

Quali altre opzioni dovrei prendere in considerazione per questo, considerando le questioni come la dimensione del database e la velocità di query (nessuno dei quali sono una grande preoccupazione a causa del volume dei dati coinvolti, ma vorrei prendere in considerazione loro almeno)

Answer 1

Hai alcune opzioni:

• salvarlo come VARCHAR (36), come hai già suggerito. Questo richiederà 36 byte (288 bit) di archiviazione per UUID, senza contare sovraccarico.
• Conservare ogni UUID in due colonne BIGINT, una per i bit meno significativi e una per i bit più significativi; utilizzare UUID # getLeastSignificantBits () e UUID # getMostSignificantBits () di afferrare ogni parte e memorizzare in modo appropriato. Questo richiederà 128 bit di archiviazione per UUID, senza contare alcun overhead.
• memorizzare ogni UUID come un oggetto; questo memorizza come la versione binaria serializzata della classe UUID. Non ho idea di quanto spazio occupa questo; Avrei dovuto eseguire un test per vedere che cosa il modulo predefinito serializzato di un UUID Java è.

I pregi e svantaggi di ogni approccio si basa su come si sta passando gli UUID intorno la vostra applicazione - se li stai passando intorno come le loro stringhe-equivalenti, poi il rovescio della medaglia che richiede il doppio della capacità di archiviazione per il VARCHAR (36) approccio è probabilmente superato dal non dover convertire i loro ogni volta che si esegue una query di DB o di aggiornamento. Se li stai passando intorno come UUID nativi, allora il metodo BIGINT probabilmente è piuttosto basso overhead.

Oh, ed è bello che si sta cercando di prendere in considerazione problemi di velocità e spazio di archiviazione, ma come molti meglio di me ho detto, è anche bene che si riconosce che questi potrebbero non essere di fondamentale importanza data la quantità di dati che il vostro app sarà memorizzare e mantenere. Come sempre, micro-ottimizzazione per il bene di prestazioni è importante solo se non farlo porta a costi o prestazioni inaccettabili. In caso contrario, queste due questioni - lo spazio di archiviazione dei UUID, e il tempo necessario per mantenere e interrogare nel DB - sono ragionevolmente basso importanza dato il costo economico di stoccaggio e la capacità degli indici DB per rendere la vita molto più facile. :)

Answer 2

1. mi sento di raccomandare char(36) invece di varchar(36). Non sei sicuro di hsqldb, ma in molti DBMS char è un po 'più veloce.

2. Per le ricerche, se il DBMS è intelligente, quindi è possibile utilizzare un valore intero per "avvicinarsi" al tuo UUID.

Ad esempio, aggiungere una colonna int al vostro tavolo, così come il char (36). Quando si inserisce nella vostra tabella, inserire l'uuid.hashCode () nella colonna int. Poi le ricerche possono essere come questo

WHERE intCol = ? and uuid = ?

Come ho detto, se hsqldb è intelligente come MySQL o SQL server, sarà restringere la ricerca da parte del intCol e poi confrontare al massimo un paio di valori da parte uuid. Usiamo questo trucco per la ricerca in milione di + record di tabelle di stringa, ed è essenzialmente veloce come una ricerca di numero intero.

Answer 3

HSQLDB ha un tipo UUID built-in. Utilizzare che

CREATE TABLE t (
  id UUID PRIMARY KEY
);

Answer 4

Utilizzando BINARIO (16) è un'altra possibilità. Meno spazio di archiviazione di tipi di carattere. Utilizzare CREATE TYPE UUID .. o Create Domain UUID .. come suggerito sopra.

Answer 5

Credo che la cosa più semplice da fare sarebbe quella di creare un proprio dominio in tal modo creare il proprio "tipo" UUID (non proprio un tipo, ma quasi).

È inoltre necessario considerare la risposta a questa domanda (soprattutto se avete intenzione di usarlo al posto di una chiave primaria "normale")

INT, BIGINT o UUID / GUID nel HSQLDB?

HSQLDB: creazione del dominio e manipolazione