I actually had the experience of using meaningful identifiers in a previous company. At that time it was really handy in a lot of day to day stuff, but I'm now thinking we might not have used them long enough to have run into the problems described here.
I feel often this is one of the major points in a trade-off: How likely is it that this choice will be thrown back in our face during the life of the application. Realistically many / most components get a rewrite soon enough. Or should have. And when they don't, it means they made back their cost many times over. After that, we don't have to actively look for trouble - we can at least modularize things somewhat so we don't have to rewrite the whole thing at once.
Personally, what I got from his story is that the management is out of touch with the technology. The only real concern I would have with meaningful identifiers, is that the public gets to decipher what the underlying data is, or aspects about the data. It’s just a privacy question. Your Trading privacy for the ability to avoid bottlenecks like reading a hard drive. As far as the management going, well, you can simply add additional indexes to that same id or data. It’s really not a big deal.
We use a Snowflake ID (the ID scheme not the company) variant that is both meaningful and gets us IDs for the next 200 or so years before having to do anything and I don't expect that will ever be an issue.
Rdio used a one-letter prefix for entity types. The company was bought & sold before it became an issue.
I agree with the author. But practically speaking, for every example where semantic IDs broke down, there are probably 10 examples where it worked out fine. Just a thought.
