I got that but I can't imagine why you would even use the User ID for anything if we're talking about the row ID from the database. If you're doing tests against a user's profile why not use their username? There must be some case-examples that I'm not thinking of...
I know that some services have a public-facing "username" and a behind the scenes unique identifier (which is a great UX model), I'm just focusing on the unique identifier. Which I would think should always be it's own column, whether it's also used for the public "username" or not.
> Because if you change that, all your relations between tables will break.
Okay, that is not a response to my question, which is why would you ever use the row ID for anything in your program. If you never use it, then it cannot ever be changed. Also SQL allows relationships based on more than one field, so it seems such a disaster could be easily avoided.
I know that some services have a public-facing "username" and a behind the scenes unique identifier (which is a great UX model), I'm just focusing on the unique identifier. Which I would think should always be it's own column, whether it's also used for the public "username" or not.
> Because if you change that, all your relations between tables will break.
Okay, that is not a response to my question, which is why would you ever use the row ID for anything in your program. If you never use it, then it cannot ever be changed. Also SQL allows relationships based on more than one field, so it seems such a disaster could be easily avoided.