Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>You have a few options:</p> <ul> <li>Store it as a VARCHAR(36), as you already have suggested. This will take 36 bytes (288 bits) of storage per UUID, not counting overhead. </li> <li>Store each UUID in two BIGINT columns, one for the least-significant bits and one for the most-significant bits; use <a href="http://java.sun.com/javase/6/docs/api/java/util/UUID.html#getLeastSignificantBits()" rel="noreferrer">UUID#getLeastSignificantBits()</a> and <a href="http://java.sun.com/javase/6/docs/api/java/util/UUID.html#getMostSignificantBits()" rel="noreferrer">UUID#getMostSignificantBits()</a> to grab each part and store it appropriately. This will take 128 bits of storage per UUID, not counting any overhead.</li> <li>Store each UUID as an OBJECT; this stores it as the binary serialized version of the UUID class. I have no idea how much space this takes up; I'd have to run a test to see what the default serialized form of a Java UUID is.</li> </ul> <p>The upsides and downsides of each approach is based on how you're passing the UUIDs around your app -- if you're passing them around as their string-equivalents, then the downside of requiring double the storage capacity for the VARCHAR(36) approach is probably outweighed by not having to convert them each time you do a DB query or update. If you're passing them around as native UUIDs, then the BIGINT method probably is pretty low-overhead.</p> <p>Oh, and it's nice that you're looking to consider speed and storage space issues, but as many better than me have said, it's also good that you recognize that these might not be critically important given the amount of data your app will be storing and maintaining. As always, micro-optimization for the sake of performance is only important if not doing so leads to unacceptable cost or performance. Otherwise, these two issues -- the storage space of the UUIDs, and the time it takes to maintain and query them in the DB -- are reasonably low-importance given the cheap cost of storage and the ability of DB indices to make your life much easier. :)</p>
    singulars
    1. This table or related slice is empty.
    1. POStoring UUID in HSQLDB database
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USdelfuego
    1. USdelfuego
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POStoring UUID in HSQLDB database
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COUmm...in what universe does 36 * 8 = 256? 36 * 8 = 288 in this one :P
      singulars
      1. PO
      1. USMetroidFan2002
    2. COAlas, I apparently live in my own universe. :/ I'll edit it.
      singulars
      1. PO
      1. USdelfuego
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload