4 ms·
You can use a UUID as a primary key and still enforce uniqueness on a combined index of city and name.
by konschubert 2y ago
You can use a UUID as a primary key and still enforce uniqueness on a combined index of city and name.
- nkozyra 2y agoIf they conflict and are user facing identifiers aren't you then forced to add uniqueness to the city and name, ala /chicago/chipotle_s4, potentially bleeding some business details? I don't love uuids as public identifiers for a number of reasons but not hinting details about your data is one nice thing about them.
- konschubert 2y agoHmm, I am not sure if I get you. The cool thing about enforcing uniqueness on a secondary index is that you can just change or remove the uniqueness constraint anytime without breaking foreign key relations.
- nkozyra 2y agoI'm not sure why you want a uniqueness index then in this case. If it's not publicly visible (effectively a secondary index / reference), then you can't use it as an identifier. This means you need something else (a slug, as discussed herein) or just use the ID (bad practice in general) or UUID (bad for humans). If you use - in this example - city and company name - you still have to enforce uniqueness, so you have a pseudo-slug anyway.
- bjourne 2y agoBut what's the point? You're complicating the data for no apparent gain. Only terrible RDBMSes which don't support multi-column keys require surrogate keys.
- konschubert 2y agoBecause you can remove or change the uniqueness constraint without having to worry about foreign key relationships.
- bjourne 2y agoEh, that's a feature of natural keys. If you try to fuck up your model your RDBMS will complain.