This is from 2011, according to the commit blame info [1]. The advice appears to be from the standpoint of LAMP development a decade ago.
[1] https://secure.phabricator.com/source/phabricator/browse/mas...
Things you should do now (2011)
61–70 of 115 posts
Re: Things you should do now (2011)
#62Things you should never do: use integers as ID's. This is literally a solved problem, and the solution is UUIDs, which were invented for exactly this job.
ULID. 128bit, human "readable", sorted (like int!), nearly impossible to guess/collide and has timestamp embedded. I love this format.
Re: Things you should do now (2011)
#63I thought we weren’t supposed to call it “blacklist” or “whitelist” anymore?
Serious answer: this is still very much in flux. We're not at the point where you'd get audible gasps from using these terms, but in certain audiences you'll get some raised eyebrows. If you believe that having "black=bad, white=good" connotations built into our jargon is harmful in some way, then yes, you should strive to use alternate terms. If you don't think that's harmful, and you're forceful in defending "black…
its not blacklist and whitelist because "black=bad, white=good", black is the abscense of light, hence the light is blocked, white would obviously be the opposite. So its black because you are blocking things, and white because you aren't.
Re: Things you should do now (2011)
#64Earlier quoted context omitted.
integer ids are still often used internally for database primary keys with UUIDs being the done thing for external interfaces. Personally I've never experienced the "whole class of bugs" that starting with a big integer is supposed to solve. I'm not using PHP so maybe that's why?
The reason (other than "don't expose integer PK externally") people say you should use integer as PK and UUID as a secondary/external facing id is that conventional B-tree indexing of UUID is not as efficient as B-tree indexing of autoinc integers in most databases. However if you want any sort of efficient lookup on the external key (UUID), your database still needs an index on the UUID, and you are back at square o…
> However if you want any sort of efficient lookup on the external key (UUID), your database still needs an index on the UUID, and you are back at square one
Yes and no. It depends on whether your database treats primary keys differently than other indexes. For example, in InnoDB primary keys are always clustered indexes: the row data is directly stored in a btree arranged by the PK; secondary indexes just store PK values in their leaf nodes, so that they can do a lookup on the clustered index.
As a result, in InnoDB smaller PKs are preferable. So performance is generally better when using an incremental ID as PK and then UUID as a secondary index, as opposed to the reverse. Assuming you have multiple secondary indexes, the total table size will also be smaller in InnoDB with integer PK than with UUID PK.
Re: Things you should do now (2011)
#65I thought we weren’t supposed to call it “blacklist” or “whitelist” anymore?
I've seen blocklist as a replacement for blacklist, but what do people use instead of whitelist?
I use 'permit_list' and 'reject_list'. Even before the colour based issue - because these names were more clear to me.
Re: Things you should do now (2011)
#66Things you should never do: use integers as ID's. This is literally a solved problem, and the solution is UUIDs, which were invented for exactly this job.
Tell that to your database which is highly optimized for using integers as IDs. Using a UUID everywhere when you could be using an integer is an invitation to low-performance-city.
Re: Things you should do now (2011)
#67Things you should never do: use integers as ID's. This is literally a solved problem, and the solution is UUIDs, which were invented for exactly this job.
No you should not. UUIDs are not always a good solution. If you order things by id (often useful for pagination, since incrementing ids are usually ordered by creation date) uuid are of no help. You would need to sort by created_at and this would require an additional index. No to speak of pagination by id ranges or whatever is used sometimes. UUIDs are mpossible to remember and thus somewhat cumbersome to use too. T…
UUIDs also introduce performance challenges. Using them as the primary key will absolutely torpedo your insert performance. They also subtly harm performance on pretty much every other operation. You can fit half (or 1/4, if you can live with 32-bit ints) as many UUIDs in a cache line, and can't even fit one of them in an integer register. The impact on join performance can be pervasive at production scale even when it's not visible at dev scale. And UUIDs tend to result in records being physically arranged in ways that defeat the page cache.
Re: Things you should do now (2011)
#68Earlier quoted context omitted.
No you should not. UUIDs are not always a good solution. If you order things by id (often useful for pagination, since incrementing ids are usually ordered by creation date) uuid are of no help. You would need to sort by created_at and this would require an additional index. No to speak of pagination by id ranges or whatever is used sometimes. UUIDs are mpossible to remember and thus somewhat cumbersome to use too. T…
Integer ID's are always a bad thing. Yes, you should be sorting things by created_at. Having another index is not a bad thing. > The weird id mixed up with index problem from the article is something which never happened to me ever in over 10 years of web development. How do you know? It's a remarkably difficult bug to detect.
When what you know just isn’t so.
Re: Things you should do now (2011)
#69Things you should never do: use integers as ID's. This is literally a solved problem, and the solution is UUIDs, which were invented for exactly this job.
agreed, this is a terrible idea.
Re: Things you should do now (2011)
#70That start ids at a gigantic number idea is great, even though I've never encountered a bug caused by not doing it.
I encountered a similar problem recently while migrating an old app. It modeled IDs as 64-bit BIGINT columns (a decision made in the 2000s) and populated them with MySQL’s UUID_SHORT function. This worked fine for over a decade until we migrated to a different MySQL system and started getting conflicts for IDs already existing or not being able to find a row which had just been inserted.
They’d missed the part that UUID_SHORT() returns an unsigned integer and created the column as the default signed integer. MySQL uses an algorithm where the top n bits are based on the server ID, which worked on the old server which had id=1 and never returned a number where the first bit was 1. The new cluster fortunately always did so the problem was immediately identified, but it was confused by one of those bonus MySQL data-destruction features – the way it silently truncated data meant that it was silently truncating new IDs to the same value but the logged value wasn’t in the database at all.