I literally came here to comment that the very first bug I had to chase down in a production system in my first job was caused by this! There was a 'fuzzy' search field available to users and when one input a client's ID number (formatted as NNNNNNN) it was showing results for a different client because NNNNNNN was also the format of the unique ID for records in the database.

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.

A better tip would be to use something like time-ordered uuids: You can‘t misuse them for something different and the added bonus is that no one can iterate your db records by just incrementing the url.

Not bugs but I've encountered a consequence which is worse than a bug.

In a recent project I arrived at, I started seeing 612 in random places in the code. It was, naturally, the ID of a very specific user. Having an easy ID to remember, it is a temptation for sloppy programmers to just hardcode certain checks against a particular ID instead of following proper procedures. It was a bad project and a bad team, and after some 10 years or so, the code was now flooded with 612 and a couple of other IDs.

Sure, you could avoid such a thing with code revisions and such, but then again it's better to simply not put the temptation in front of the programmers, isn't it?

I once debugged a case where the id had left sided zero padding so the whole id length was a fixed number of digits, for example `238974` might be represented as `00238974`.

In a process that joined two tables the match counts were off. Somehow, on one side of the join the id was being converted to an integer and then back to a string, which stripped the zero padding. Meaning that `00238974` was failing to match `238974`.

Sigh.

Indeed, that and sql syntax errors are solved by using an orm or sql code generator like sql alchemy core.

I like that pattern too. I've tried using it in a rather ad-hoc way in C/C++ enums. I suppose the proper solution would be to have a header file, enum_starting_vals.h, to centralise them.