4 ms·

Good question. I'm somewhat inclined to say if we're uniquely identifying resources with a unique, human-readable string, that's the ID you should always use t

Good question. I'm somewhat inclined to say if we're uniquely identifying resources with a unique, human-readable string, that's the ID you should always use to refer to things. It seems slightly more complicated to explain to users that there are these two ways to refer to things. There's also the issue (or benefit) of keeping the UUID the same if you are able to change the human-readable ID.

verdverm 4y ago
It's not so different from users, ids, and display names
cratermoon 4y ago
In that case, you're going to run into the same problem that happens with any organizational naming: names aren't stable. Reorgs happen. Buyouts happen. Rebranding happens. Even people's names change. Anyone who has ever worked at a moderately-sized company that got bought or renamed, knows the hell of The Renaming. And there's always things left out. Are you going to go through and change all package names in your code? Or are you going to be left with a fragile bit of tribal knowledge or obscure documentation explaining what "oldname" means everywhere? And don't even get me started on auth checks and someone spoofing the system because something still accepts the old identifier long after the original owner gave it up and some malicious party grabs it.
- verdverm 4y ago
  This has nothing to do with the user's question. What you describe is at the code level naming patterns, what OP is asking about is database columns, and fairly standard queries at that.
  - cratermoon 4y ago
    The Naming Problem applies, I just used package names as an example. How many times have you seen a network, computer, project, or whatever named for something that no longer exists? The OP mentioned "Github organization / repo names" specifically. I know of github repos that are less than a year old and already refer to teams that don't exist any more. I presumed that's what was meant by "human readable IDs". Now if the "human readable" just means something like "pronounceable words", well, the only problem is no matter what language is chosen for those words, there will likely be someone who doesn't know what they mean, so they are just gibberish anyway.

verdverm 4y ago

It's not so different from users, ids, and display names

cratermoon 4y ago

In that case, you're going to run into the same problem that happens with any organizational naming: names aren't stable. Reorgs happen. Buyouts happen. Rebranding happens. Even people's names change. Anyone who has ever worked at a moderately-sized company that got bought or renamed, knows the hell of The Renaming. And there's always things left out. Are you going to go through and change all package names in your code? Or are you going to be left with a fragile bit of tribal knowledge or obscure documentation explaining what "oldname" means everywhere? And don't even get me started on auth checks and someone spoofing the system because something still accepts the old identifier long after the original owner gave it up and some malicious party grabs it.

verdverm 4y ago
This has nothing to do with the user's question. What you describe is at the code level naming patterns, what OP is asking about is database columns, and fairly standard queries at that.
- cratermoon 4y ago
  The Naming Problem applies, I just used package names as an example. How many times have you seen a network, computer, project, or whatever named for something that no longer exists? The OP mentioned "Github organization / repo names" specifically. I know of github repos that are less than a year old and already refer to teams that don't exist any more. I presumed that's what was meant by "human readable IDs". Now if the "human readable" just means something like "pronounceable words", well, the only problem is no matter what language is chosen for those words, there will likely be someone who doesn't know what they mean, so they are just gibberish anyway.