Constraints on usernames?
-
Well, I'm a bit split about this. If I allow that, what do I do when two users have the same email address?
-
Well, I'm a bit split about this. If I allow that, what do I do when two users have the same email address?
Obviously if you allow login via email address, you require a unique email address. This scenario should be a non-issue.
Duh.
-
My point is that there's no reason 124893859 is a better identifier for a user than username_they_signed_up_with.
If you're committing to their username never ever cross your heart swear on your mother's grave changing, then it's OK. I suppose you have the power to tell people to STFU if they want that sort of feature. I always use a surrogate key because it saves me headaches and keeps things standardized.
-
If you're committing to their username never ever cross your heart swear on your mother's grave changing, then it's OK. I suppose you have the power to tell people to STFU if they want that sort of feature. I always use a surrogate key because it saves me headaches and keeps things standardized.
It also doesn't lock you into a certain set of features. If ben decides to use the username as his PK, but later changes his mind about the whole changing username thing, he'll be in for a huge headache.
-
Exactly.
-
It also doesn't lock you into a certain set of features. If ben decides to use the username as his PK, but later changes his mind about the whole changing username thing, he'll be in for a huge headache.
Hell, just a simple additional unique key would help. Use username as primary by default. If you change your mind later just switch to using that unique key instead and Bob is your mother's brother.
-
Hell, just a simple additional unique key would help. Use username as primary by default. If you change your mind later just switch to using that unique key instead and Bob is your mother's brother.
You're still in for the headache of switching your schema over to using the alternate key instead. Depending on how many relationships you have set up, that can be a huge PITA.
-
True. But at least it's "just" a PITA, compared to a fustercluck you'd be in otherwise.
Using a unique key in the first place is the best solution, but we're either getting trolled something fierce or ben is really determined not to do that.
-
It's not that he isn't going to use a unique key. It's that he's falling into the natural key trap instead of just using a surrogate key like civilized people do.
-
but we're either getting trolled something fierce or ben is really determined not to do that.
I am guessing the key to the aversion is the use of NoSQL which makes enforcing uniqueness of the username more work if it is not the key in the map.
-
And the username is the only part of the user that needs to be unique!
-
I don't understand how "look up name in sorted table referenced by GUID in field" is easier than "name in field".
If a user had the name
yoloswaglord420when they made a post, that post will forever be known as a post made byyoloswaglord420.Post was made by user
{1F7CB49D-FDA6-4C6D-B7E1-968E63A1FF6D}, you just look upyoloswaglord420(or the new name if it changes) when you want to render user{1F7CB49D-FDA6-4C6D-B7E1-968E63A1FF6D}'s post...
-
But I can do that with a display name and a lookup by username. I don't need to artificially introduce GUIDs to the system.
-
MongoDB supports unique constraints just fine.
Ben L hasn't told us what DB he's using.
-
Well, I'm a bit split about this. If I allow that, what do I do when two users have the same email address?
Have you ever met two people with the same [spoiler]primary[/spoiler] email address?
Filed under: futile counter-pendantry measures
-
I have. My parents.
-
But I can do that with a display name and a lookup by username. I don't need to artificially introduce GUIDs to the system.
If that's what you want to do. I'm not sure whether as a user I'd be particularly interested in a system which I have to sign in as
dirty_bobs_ballsin order to post asHoly Batman! MY PUBES ARE ON FIRE!, but maybe I'm not the target demographic anyway...
-
Have you ever met two people with the same [spoiler]primary[/spoiler] email address?
My wife and I have a shared email account that we use for things like our credit cards and the mortgage statement. That way it's easily accessible to whoever is doing the bills each month.
primary
Oh, carry on.
-
Hmm, should I do login via OpenID?
<ben_lubar is obviously trolling, right?>
-
If you change a user's username, you break everything that links to that user anyway
Only if you're @CodingHorrorBot
-
@JazzyJosh Is Doing It Wrong™
-
Well, it's happened on a certain Community Server forum I've used. It's happened on a certain phpBB forum I've used. It hasn't happened on a bbPress forum because they don't allow changing of usernames.
-
Have you ever met two people with the same primary email address?
I have seen people with a addresses like BobAndJaneSmith@example.com. Even people who are otherwise intelligent.
-
Can you even change your username on Steam
Your display name, yes. Your login name, no.
-
MongoDB supports unique constraints just fine.
And hadoop.
My parents.
Mine as well if we are tallying.
-
-
Well, technically, the MS system doesn't have a username; it uses the e-mail address in lieu
Not quite. I have a Microsoft ID that I have used for a very long time with the login name as my email address. Recently, I switched my email over to an Office 365 subscription. Now I have a second login with the same email address, but the second one is a completely different identity. If the login box says "Login with your Work or School Account", then I use the second account. If it says "Microsoft Login", then I use the one that was formerly referred to as "Microsoft Passport".
They are two logins, with different passwords and both have completely different rights to stuff, but both have the same login name. Microsoft definitely doesn't use the email address as the primary key of the users table.
-
Ban Dragonball Z character names.
I'm working on that, plus all Shonen Jump canon, plus misspellings of the aforementioned, plus the aforementioned enclosed in X's and Z's.
-
@Captain, post:35 topic:8913 said:
I think it's different usage. We're talking about it in terms of how databases implement keys, whereas the theory calls unique properties "primary keys".
Who's theory?
Look, primary keys by necessity have to be marked UNIQUE. But you can also have UNIQUE constraints on non-keys, even in some NoSQL systems (I know MongoDB supports it, for example.)
My understanding is that "primary" also implies "one." There can be one primary key, but multiple surrogate keys.
-
Captain said that unique properties were primary keys, which is only partially true. blakeyrat correctly pointed out that primary keys are always unique, but unique keys are not always primary. Your statement does not refute blakeyrat's statement, nor does it reinforce Captain's.
Also, the phrase you are looking for is "candidate key". A key can be either natural or surrogate. It's natural if it's comprised of data from the entity and surrogate if it's not.
-
If you change a user's username, you break everything that links to that user anyway, which is why I'm disallowing changes of usernames.
This is why we use surrogate keys that have no material value to the user (and are ideally hidden from the user). That way, usernames can change without breaking anything!
Hey, check out my profile here [link to /u/oldusername]
Then pull a Discourse or something like /u/12345/oldusername...
I'm not sure why looking up some 8-byte block of serialized data is harder or easier than looking up any other byte sequence in a b-tree.
That depends on whether or not fragmentation is an issue with your database.
Why does
{1F7CB49D-FDA6-4C6D-B7E1-968E63A1FF6D}identify a user better thanyoloswaglord420?The former uniquely identifies a user. The latter uniquely identifies a douchebag.
-
This whole topic is just a big bait and switch... @ben_lubar sounds like he is going to end up with basically the correct schema, he's just naming things retardedly in order to get a rise out of all of the tdwtfers.
-
Your statement does not refute blakeyrat's statement, nor does it reinforce Captain's.
My intention was the opposite. One primary key per table at maximum, but you can have multiple unique keys.
Also, the phrase you are looking for is "candidate key".
Yes, you are correct. 'Twas a brainfart.
-
We still haven't solved the original issue of "what characters do we allow in usernames"
-
We still haven't solved the original issue of "what characters do we allow in usernames"
Who gives a shit. If you don't have any injection vulnerabilities, then what people want to call themselves is of no concern to you.
-
Look, I understand that some people want to be called ‧̴̵̶̷̸̡̢̧̨̛̖̗̘̙̜̝̞̟̠̣̤̥̦̩̪̫̬̭̮̯̰̱̲̳̹̺̻̼͇͈͉͍͎̀́̂̄̃̅̆̇̈̉̊̋̌̍̎̏̐̑̒̓̔̽̾̿̀́͂̓̈́͆͊͋͌̕̚ͅ͏͓͔͕͖͙͚͐͑͒͗͛ͣͤͥͦͧͨͩͪͫͬͭͮͯ͘͜͟͢͝͞͠͡, but what about three spaces followed by two U+0000 and then another space?
Or a zero-width non-breaking space?
Or an empty string?
-
-
Other tags from Community server include:
- 👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳👳
- """"""""""""""""""""""""""""""""""""""""""&qu
- """"""""""""""""""""""""""""""""""""""""""&am
- apkerch ıpǝɐs
- Breast Programming
-
Look, both Twitter and Steam refer to people by big-ass serial numbers and link all their data to those big-ass serial numbers instead of usernames.
If you don't want to follow their example, fine. You're being stupid, but fine.
-
-
Just don't show them their username on the screen anywhere other than them having to input it to log in (because you have a display name), and then who cares what characters they use. it'd be their own ease of use that they'd be screwing over.
then debate could be over what characters to allow in the display name!
That only allows two users
damn typos and what the hell was i smoking..... ^\d{1,12}$had to go fix the earlier one too...
-
Must like MP, even if it is a complete non-sequitur in the context of the post to which it is replying, or even the topic in general.
-
I'm thinking of using the usernames as primary keys in a NoSQL database, since all the keys in NoSQL databases are strings anyway.
Don't know what's the use case, but can be OK. No need to make everything into a huge production, if you just need a simple user system.
Also OK to require reduced character set for usernames. Alphanumerics and such. Depends on what market you're shooting at.
EDIT AFTER READING EVERYTHING:
So a forum? Hmm... people will need an ID they can easily type in. Email is annoying to type, so it will probably be some kind of username. So there's already a stronger case for using it as PK.
Others have pointed out good reasons why you might want a pseudokey. But there are good reasons against it too. Makes things simpler. Less unique things to check and keep track of. Data is easier to read too. Eventually you'll end up needing to do a quick ad-hoc query against a user PK, and you'll be glad it's not a GUID then. Architects never consider stuff like that, but it's what happens in reality. Maybe not on the level of twitter, but in a little forum, definitely.
I'd go with a username as PK.
That also informs allowed chars stuff. Since this will be used as a key all over the place, you need something sane. I'd go with [a-zA-Z_0-9-]. Maybe even without a dash. If people really want a strange ass crap or UTF chars, they can have a "display name" or something.
-
Eventually you'll end up needing to do a quick ad-hoc query against a user PK, and you'll be glad it's not a GUID then.
Nothing is stopping you from having a unique index on the username regardless of the PK and doing a query on that in 99.9999% of the cases. Any queries targeting the PK specifically will mostly be
JOINs (however you do that with a NoSQL database) or something resulting from clicking a link anyway, nobody is going to type it in manually. So I really don't see a problem there.I concede that GUIDs could be a bit of pain at times, but they are a necessary evil if integers cannot be used. Which is stupid by itself IMHO, but yay NoSQL.
-
You mean this Steam?
Steam Community :: Blakeyrat
Friends everywhere, if only you know where to look. Friends in all shapes, all sizes, all places!
I'm very late to the party, but this bit needs to be pointed out:
Steam has [i]three[/i] names: The account name, the display name, and the [i]URL[/i] name.
The account name could easily be renamed "Login name", because that's pretty much all it is ever used for. It doesn't change.
The profile name takes a default of your account (Login) name when you first sign up, but you can change it however many times you want. It's not even unique.
The URL name [i]is[/i] unique and it has [i]no default value[/i]. You must go into your profile and set it yourself, but you can still change it as many times as you want.
-
This is why standardized education is useful: shared terminology.
Steam has three names: The account name, the display name, and the URL name.
Facebook does the URL name thing too
-
Microsoft definitely doesn't use the email address as the primary key of the users table.
Of course they don't; never said they did. Knowing MS, it's almost certainly a GUID primary key.And if you had actually read what I wrote, you'd see I was talking about usernames, not primary keys
-
Nothing is stopping you from having a unique index on the username regardless of the PK and doing a query on that in 99.9999% of the cases. Any queries targeting the PK specifically will mostly be JOINs (however you do that with a NoSQL database) or something resulting from clicking a link anyway, nobody is going to type it in manually. So I really don't see a problem there.
I concede that GUIDs could be a bit of pain at times, but they are a necessary evil if integers cannot be used. Which is stupid by itself IMHO, but yay NoSQL.
Joins are (usually) possible but less desirable in NoSQL. But even if he used SQL, wouldn't this:
SELECT * FROM user_activity WHERE username IN ("joe", 'joe1', 'joe11', 'joe-fu-admins');be easier than this
SELECT * FROM user_activity ua INNER JOIN users u on u.id = ua.user_id WHERE ua.username IN ("joe", 'joe1', 'joe11', 'joe-fu-admins');I'm not saying it's impossible to do things with pseudokeys. Just that things are a tiny bit more complicated all over the place. So it's a good tradeoff to just KISS and use usernames. IMO.
-
wouldn't this...be easier than this
As I said before, it's a short term win for easy, but possibly a big long term loss.
So it's a good tradeoff to just KISS and use usernames.
Ugh.
-
As I said before, it's a short term win for easy, but possibly a big long term loss.
Sometimes you need a short-term easy win to survive long enough for the long term to become possible.
