User Data Table(s)

[ghost]

I'm proposing some possible table structures to get us rolling. What does everyone think of this for user data?

User Table: id, firstname, lastname, password, createtime User_Email Table: user(user.id), email, createtime User_Handle Table: user(user.id), handle, createtime User_Role Table: user(user.id), role(role.id), {action} createtime

I'm probably missing stuff. Any ideas?

[jarofghosts]

whats the benefit of splitting these up?

[ghost]

@jarofghosts I think the benefit to splitting up the user_email and user_role is primarily the ability to maintain a one to many relationship. To me, the reason for maintaining a user_handle table separately also applies to e-mail (and the post data conversation): we can do updates and maintain historic data--no need for overwrites. For instance, maintaining historic data means we could maintain references to deprecated handles so that they don't dead end (like they do on twitter), or something.

[jarofghosts]

so we dont maintain historical data about updated first and last names?

[hedgerh]

@beingbrown, aside from references, are there any other benefits to tracking handle changes?

[robotmayo]

Steam does it. Its useful to know what a user was known by. Although I think on a forum allowing unrestricted handle changes isn't the best idea. On a forum I used to administrate we had limited periods of time where a user could change their handle.

[ghost]

looking over my notes, I also have the idea of storing the way in which we confirm e-mails. I know this is important for some of the other projects I have going on (mostly involving students). Is that a big worry here?