Tim Lesher wrote: > 1. First principles: the absolute minimum a user table needs is a > unique string to identify a user. Theoretically, the user table's PK > suffices, but that's probably not enough to let a user log in, so > we'll need some string-based representation.
[...] > 3. The majority (but not as many as #2) will probably want a > "displayable" string that's more friendly than #1. It's a slim enough > majority that we probably can't assume it, though. I would disagree with this. Most web sites I use simply display the username. About the only exceptions are e-commerce sites, and they tend to display a combination of first name and surname, which are definitely not used in the majority of applications, and would tend to be 2 separate fields anyway. In many cases this is likely to be derived from other fields (eg. capitalize(username), or first + last name) so I expect it would often be implemented as a method rather than a field. > 4. It seems to me that most public-facing apps that require an email > address will use it as the uniquely-identifying string I don't see much evidence that this would be the case. Often you enter a username and then enter an email address later to verify your account, receive update notifications, etc. Email addresses change, unique identifiers generally should not. > so that should > be large enough to hold an email address, and should be named in a > content-neutral way I agree that if a string is used as the unique user ID, then making it long enough to hold an email address is a very sensible idea, even though few sites I know use email in that way. -- Ben Sizer --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~----------~----~----~----~------~----~------~--~---
