From ccdb28c7fedbe8de3207f83ee5521d6cc5cb3123 Mon Sep 17 00:00:00 2001 From: Joe Ardent Date: Mon, 26 Jun 2023 12:16:33 -0700 Subject: [PATCH] checkpoint --- content/rnd/a_serialized_mystery/index.md | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/content/rnd/a_serialized_mystery/index.md b/content/rnd/a_serialized_mystery/index.md index 7191f48..1587750 100644 --- a/content/rnd/a_serialized_mystery/index.md +++ b/content/rnd/a_serialized_mystery/index.md @@ -24,7 +24,7 @@ folly](@/sundries/a-thoroughly-digital-artifact/index.md)! # Keys, primarily Most large distributed programs that people interact with daily via HTTP are, in essence, a fancy -facade for some kind of database. Facebook? Database. Gmail? Database. +facade for some kind of database. Facebook? That's a database. Gmail? That's a database. ![that's a database][thats_a_database]
wikipedia? that's a database.
@@ -35,7 +35,8 @@ it's in. Since databases typically contain multiple tables, and primary keys hav within their own table, you could just use a simple integer that's automatically incremented every time you add a new record, and in many databases, if you create a table without specifying a primary key, they will [automatically and implicitly use a -mechanism](https://www.sqlite.org/lang_createtable.html#rowid) like that. +mechanism](https://www.sqlite.org/lang_createtable.html#rowid) like that. You may also recognize the +idea of "serial numbers", which is what these sorts of IDs are. This is often totally fine! If you only ever have one copy of the database, and never have to worry about inserting rows from a different instance of the database, then you can just use those simple @@ -47,12 +48,12 @@ fancier identifier for your primary keys, to avoid collisions between primary ke ## UUIDs -One very common type for these is called a -[UUIDv4](https://datatracker.ietf.org/doc/html/rfc4122#page-14). These are 128-bit random +A popular type for these is called a +[v4 UUIDs](https://datatracker.ietf.org/doc/html/rfc4122#page-14). These are 128-bit random numbers[^uuidv4_random], and when turned into a string, usually look something like `1c20104f-e04f-409e-9ad3-94455e5f4fea`; this is called the "hyphenated" form, for fairly obvious reasons. Although sometimes they're stored in a DB in that form directly, that's using 36 bytes to -store 16 bytes' worth of data, which is more than twice as many bytes than necessary. And if you're +store 16 bytes' worth of data, which is more than twice as many bytes as necessary. And if you're a programmer, this sort of conspicous waste is unconscionsable. You can cut that to 32 bytes by just dropping the dashes, but then that's still twice as many bytes @@ -83,4 +84,8 @@ desire to be "efficient". [^uuidv4_random]: Technically, most v4 UUIDs have only 122 random bits, as six out of 128 are reserved for version metadata. +[^blob-of-bytes]: Some databases have direct support for 128-bit primitive values (numbers). The +database I'm using, SQLite, only supports up to 64-bit primitive values, but it does support +arbitrary-length sequences of bytes called "blobs". + [thats_a_database]: ./thats_a_database.png "that's a database"