On 3/4/2011 2:41 PM, Rob Marscher wrote:
Some nice thoughts. Thanks for sharing.
On Mar 4, 2011, at 2:30 PM, Gary Mort wrote:
Get rid of 2 of them. And the one that makes the most sense to keep is
username.
There's probably some sites where people don't even want to bother creating a
usern
On 3/4/2011 3:07 PM, D. J. Waletzky wrote:
I'd say that unless you have more than 4000 users (depending on the
limits of your db host) you can probably get away with keeping the
number of tables small and the numbers of columns somewhat high. It's
always best to run some sample queries to get a
On 3/4/2011 2:30 PM, Gary Mort wrote:
Oh, and get rid of that password as well. It doesn't need to be in
that table and because it is assumed to be there, I have to do some
really hackish things when one wants to authenticate in some other way.
I've kept the password in a separate tabl
The problem with eliminating "redundant" info in a user table is that it
may not scale terribly well. I always take care to give any user table
an auto_incremented row number/uid, because the user's handle and
e-mail, though unique, may change. Without an independent index
changing either of these
Some nice thoughts. Thanks for sharing.
On Mar 4, 2011, at 2:30 PM, Gary Mort wrote:
> Get rid of 2 of them. And the one that makes the most sense to keep is
> username.
There's probably some sites where people don't even want to bother creating a
username and just use an email address. But
After a number ofodd fights with user tables I'm coming the
conclusion that Mitch is right.
The typical user table starts with 3 bits of information:
A userid
A username
An email address.
A one way encrypted password
MaybeMAYBE some user status info...
And it demands that the first thr
