5 ms·

Why would you use anything but a string for User IDs? My understanding of numerical types is that they exist to perform math. User IDs are not used for math, t

Why would you use anything but a string for User IDs? My understanding of numerical types is that they exist to perform math. User IDs are not used for math, they're a completely arbitrary vanity system to assist with identification, so they should be strings, equally arbitrary. Personally, I think E-mail addresses are the best user identifiers these days. Back in the day when there were like 5 websites everyone used, having your username was a cool thing. These days there's a billion websites and nobody uses the same ones and there's zero inter-user interaction on most sites. From the perspective of user friendliness, E-mail addresses are the easiest because you kill two birds with one stone (contact method + username + password recovery). If you want a numerical ID, what about using a hash of the E-mail address? Or perhaps a combination of things, email, full name, sign-up date.

StavrosK 8y ago
> E-mail addresses are the best user identifiers these days Oh god no. You don't want all your IDs changing when a user changes their email address. You probably want your ID (e.g. a UUID) and your user-friendly lookup method (e.g. an email) to be separate.
- originalsimba 8y ago
  > 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?
  - detaro 8y ago
    The article doesn't use "User ID" in the sense of "username" (externally visible identifier, that likely is used for log in), but as in "mostly internal id thats used to reference a user across database tables, services, ...". If you use something that can change in there, you need to do the change across all those things consistently, which is a lot of potential for error. Or am I misunderstanding your perspective?
    - StavrosK 8y ago
      That's exactly it, and the article doesn't talk about user-facing usernames, since they're automatically incrementing ints.
      - originalsimba 8y ago
        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.
        StavrosK 8y ago
        Because if you change that, all your relations between tables will break.

StavrosK 8y ago

> E-mail addresses are the best user identifiers these days Oh god no. You don't want all your IDs changing when a user changes their email address. You probably want your ID (e.g. a UUID) and your user-friendly lookup method (e.g. an email) to be separate.

originalsimba 8y ago
> 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?
- detaro 8y ago
  The article doesn't use "User ID" in the sense of "username" (externally visible identifier, that likely is used for log in), but as in "mostly internal id thats used to reference a user across database tables, services, ...". If you use something that can change in there, you need to do the change across all those things consistently, which is a lot of potential for error. Or am I misunderstanding your perspective?
  - StavrosK 8y ago
    That's exactly it, and the article doesn't talk about user-facing usernames, since they're automatically incrementing ints.
    - originalsimba 8y ago
      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.
      - StavrosK 8y ago
        Because if you change that, all your relations between tables will break.