2 ms·
I think ideally your primary key is whatever makes sense for your performance/data model, and then if you want to delegate authority with UUIDs you do that via
by staticassertion 5y ago
I think ideally your primary key is whatever makes sense for your performance/data model, and then if you want to delegate authority with UUIDs you do that via a separate mapping.
By separating that out you can get a lot:
1. You can extend your delegate system by modifying the delegate table, rather than having to muddy your data model with authority information
2. You can TTL the mappings in the delegate table
3. You can have many mappings to the same data, but each one can have its own restrictions.
It's a bit more complex but you end up with a system that really hones in on the benefit that you're bringing up.
- weird-eye-issue 5y agoThat sounds really overkill for simply wanting an identifier that doesn't change, isn't guessable, and doesn't reveal how many rows there are
- staticassertion 5y agoWe'll have to agree to disagree. Systems like the ones I described are a hell of a lot easier to build on long term while maintaining those invariants.
- weird-eye-issue 5y agoHow is that easier to maintain than literally just having a UUID primary key? I feel like we must be talking about different use cases
- staticassertion 5y agoIf your goal is to use the uuid as a delegated capability it's going to be much more complex to use the primary key for your row than to use a separate key.
- weird-eye-issue 5y agoYeah we are talking about different use cases entirely