47 lines
1.4 KiB
Markdown
47 lines
1.4 KiB
Markdown
# 4. UUIDs for primary keys
|
|
|
|
Date: 2024-05-31
|
|
|
|
## Status
|
|
|
|
Proposed
|
|
|
|
|
|
|
|
## Context
|
|
|
|
We need primary keys in our database.
|
|
|
|
I've used integers and UUIDs for this in different contexts. Ultimately, we have
|
|
to decide on which one to use.
|
|
|
|
|
|
## Decision
|
|
|
|
We're going to use UUIDs for our primary keys.
|
|
|
|
The primary motivation here is that it will give us the ability to generate IDs
|
|
before inserting records, and it lets us expose the IDs more easily. Instead of
|
|
either leaking information (count of users, etc.) or having a secondary mapping
|
|
for URLs, we can easily use the ID in a URL to map to a record for lookup.
|
|
|
|
|
|
## Consequences
|
|
|
|
There are some drawbacks:
|
|
|
|
- We lose some type safety, becasue SQLite only supports text/blob types and
|
|
it's been a blocker trying to implement custom sql types in Diesel, so this is
|
|
going to be done by converting to strings and operating on these IDs as
|
|
strings.
|
|
- They take up more space
|
|
|
|
However, we get these benefits:
|
|
|
|
- We can expose primary keys without leaking information. This makes it so we
|
|
do not need secondary IDs (and associated indexes) for looking up specific
|
|
records and putting them in URLs, where if we used integers we'd need that or
|
|
we would have to accept exposing the number of records we have.
|
|
- IDs are unique across tables, so they should give us the ability to find a
|
|
particular row even if we don't know the table. This also means we could link
|
|
events, like edit events, to any table via UUID.
|