1.4 KiB
1.4 KiB
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.