> Oh god no. You don't want all your IDs changing when a user changes their email address.
That's a pretty passionate response, can you explain your logic? What are you doing with your usernames that you can't afford to let users change them?
That's a pretty passionate response, can you explain your logic? What are you doing with your usernames that you can't afford to let users change them?
Or am I misunderstanding your perspective?
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.