On 6/10/17 8:13 AM, R Smith wrote:
In that worst case scenario (all of the UUID plus dashes and braces),
the full storage requirement for a UUID would look like this:
{xxxxxxxx-xxxx-Axxx-Bxxx-xxxxxxxxxxxx} which totals 38 characters of
ASCII (or UTF-8) text space which totals 38 bytes.
Let's be generous and assume the user made VARCHAR(40) provision on an
old-style DB which reserves all the bytes, or better yet, a modern one
with a length definition that takes a further 32-bit value, so 42
bytes then. Even in this very worst case scenario, the full space
requirement for a UUID is a dismal ~2.7 times more than the 16 bytes
of space the original 128-bit value consumed. Let's further assume the
worst text storage system using DBCS to store 16 bits per character
(and nobody really does this), even then we only get to just over 5
times. Where did he get 9 times from??
The typical usage, storing full text UUID minus braces in an
ASCII/UTF-8 sequence will result in a hair over 2.3 times[1] the
storage of INTs. Not really that bad I think.
If the field was declared as char[38], and UNICODE collation, many
systems will allocate 4 bytes per character to allow for any possible
character (of course, since we are only storing ASCII characters, we
need to declare that so they take only 1 byte per character). Comparing
that to 128 bits (16 bytes) is the 9x factor.
Richard Damon
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
