Memorizzazione UUID nel database HSQLDB

Question

Desidero memorizzare UUID creati utilizzando java.util.UUID in un database HSQLDB.

L'opzione ovvia è semplicemente archiviarli come stringhe (nel codice che verranno probabilmente considerate come tali), ad esempio varchar (36).

Quali altre opzioni devo considerare 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

avete alcune opzioni:

• Conservare come VARCHAR (36), come hai già suggerito. Ciò richiederà 36 byte (288 bit) di memoria per UUID, senza contare l'overhead.
• Archiviare ciascun UUID in due colonne BIGINT, una per i bit meno significativi e una per i bit più significativi; utilizzare UUID#getLeastSignificantBits() e UUID#getMostSignificantBits() per afferrare ciascuna parte e memorizzarla in modo appropriato. Ciò richiederà 128 bit di memoria per UUID, senza contare alcun sovraccarico.
• Archiviare ciascun UUID come OGGETTO; questo lo memorizza come la versione serializzata binaria della classe UUID. Non ho idea di quanto spazio occupi; Dovrei eseguire un test per vedere quale sia la forma serializzata predefinita 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 memorizzazione per l'approccio VARCHAR (36) è probabilmente superato il fatto di non doverli convertire ogni volta che si esegue una query o un aggiornamento DB. Se li stai passando in giro come UUID nativi, probabilmente il metodo BIGINT è piuttosto basso.

Oh, ed è bello che tu stia considerando i problemi di velocità e spazio di archiviazione, ma come molti meglio di me hanno detto, è anche positivo che tu riconosca che questi potrebbero non essere di fondamentale importanza data la quantità di dati tua l'app verrà archiviata e gestita. Come sempre, la micro-ottimizzazione per il massimo delle prestazioni è importante solo se ciò non comporta costi o prestazioni inaccettabili. Altrimenti, questi due problemi - lo spazio di archiviazione degli UUID e il tempo necessario per gestirli e interrogarli nel DB - sono ragionevolmente bassi, dato il costo economico dello storage e la capacità degli indici DB di renderti la vita molto più facile. :)

Answer 2

Penso che la cosa più semplice da fare sarebbe creare il proprio dominio creando così il proprio "tipo" UUID (non proprio un tipo, ma quasi).

Si dovrebbe anche prendere in considerazione la risposta a questa domanda (soprattutto se avete intenzione di usarlo al posto di una chiave primaria "normale")

INT, BIGINT or UUID/GUID in HSQLDB?

HSQLDB: Domain Creation and Manipulation

Answer 3

1. Suggerirei char(36) anziché varchar(36). Non sono sicuro di hsqldb, ma in molti char DBMS è un po 'più veloce.

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

Ad esempio, aggiungere una colonna int alla tabella e il carattere (36). Quando inserisci nella tua tabella, inserisci 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 dal uuid . Usiamo questo trucco per cercare oltre milioni di tabelle di record per stringa, ed è essenzialmente veloce come una ricerca di interi.

Answer 4

L'utilizzo di BINARY (16) è un'altra possibilità. Meno spazio di archiviazione rispetto ai tipi di carattere. Usa CREATE TYPE UUID .. o CREATE DOMAIN UUID .. come suggerito sopra.

Answer 5

HSQLDB has a built-in UUID type. Use that

CREATE TABLE t (
    id UUID PRIMARY KEY 
);