4 ms·
"Use UUIDs instead of integer PKs" is 95% of the time a HORRIBLE idea. As a rule of thumb, if you are a beginner, you should NEVER use a UUID instead of an int
by stevecalifornia 10y ago
"Use UUIDs instead of integer PKs" is 95% of the time a HORRIBLE idea. As a rule of thumb, if you are a beginner, you should NEVER use a UUID instead of an integer PK.
If you know the definition and the ins-and-outs of 'clustered index', 'index fragmentation' and 'page split' then feel free to use a UUID if you see fit-- otherwise, please don't.
If you are a beginner and for some reason have to have a UUID: Use a sequential, auto-incrementing integer for your clustered index column and make another second column that is your primary key that is your UUID.
This article feels like the blind leading the blind.
- Jweb_Guru 10y agoPostgres doesn't have clustered indices. Index fragmentation and page split are not problems unique to UUIDs, especially in databases with clustered indexes (unless you never issue UPDATEs).
- hobs 10y agoAlso feel free to use the "bottom" of the keyspace instead of zero to start your keys if your database uses signed integers. (MSSQL I am staring at you)
- aianus 10y ago> "Use UUIDs instead of integer PKs" is 95% of the time a HORRIBLE idea. As a rule of thumb, if you are a beginner, you should NEVER use a UUID instead of an integer PK. Can you enlighten us as to why? Seems to me if you're not at the scale where you see the benefits of UUIDs you're also not at the scale to see the drawbacks either (bigger, slower indices?).
- balls187 10y agoPoor index performance effects all your queries, regardless of scale. Better more practical advice might be: if you don't need to use a X as a PK, don't use a X as a PK. Where X can be either UUID or BIGINT. If you don't expect your table to scale past a billion rows, INT is more than fine.