> Ever had an id in front of you and you weren't necessarily sure which database table it belonged to? I'm not sure I've ever been in a situation where I had a

> Ever had an id in front of you and you weren't necessarily sure which database table it belonged to? I'm not sure I've ever been in a situation where I had a random ID and absolutely no information otherwise as to what it might be, real-life or otherwise. I really dislike IDs that just repeat information that is captured elsewhere, such as the type of the underlying object or date-time information. It reminds me of coding conventions in primitive languages where you need to prefix every variable name with a type, such as str_my_var. Long IDs with a bunch of common information also have the nefarious effect of appearing more random than they really are. "Profile_1gsd9e" looks more unique than just "1gsd9e", but barely adds any extra entropy (https://gist.github.com/4k1/6fbe670807db1d48407685d6cc46b0af https://gist.github.com/4k1/6fbe670807db1d48407685d6cc46b0af). Also, by prefixing random IDs with table information, you're revealing the underlying structure of your database to a bad actor. Don't reveal unnecessary information about the structure of a database or network when you don't have to. I'm not really one to care about "clean code conventions", but this might be one I could endorse - don't clutter IDs with extraneous information.