the id is definitely better.  although creating an index on the email and
potentially the password would help.  I had a table that was indexed off of
a random unique string and when i got to about 50000+ rows updates were
taking about 4 seconds.

you can authenticate with the email and password, but then i would run all
updates based on the ID, and if you need to be sure of authentication,
store them in session variables and use them when you need them.

if you want to keep it the way you have it, i'd just add indexes on those

i'm sure there are better ways but, .....


                    <[EMAIL PROTECTED]       To:     [EMAIL PROTECTED]                  
                    om>                  cc:                                           
                                         Subject:     [PHP-DB] Index on email or ID?   
                    09:23 AM                                                           


My website requires subscribed users to login with their email and
the email is guaranteed to be unique, so this is one key, the other is the
AUTO_INCREMENT ID assigned at registration time.

In the cookie that I drop at logon time is the email/password combination
(security isn't really a major issue) I can then use the email as
the unique key into the user table. Of course, I could also drop the
AUTO_INCREMENT ID at logon time aswell, so instead of having:

   WHERE email = '[EMAIL PROTECTED]' AND password = 'userpass'

I would use:

   WHERE id = 19 AND email = '[EMAIL PROTECTED]' AND password =

Question is, is the index performance on a INT column much greater than
of a VARCHAR column? My guess would be yes.

Also, if your thinking about saying "well if ya got the ID, why bother with
email and password", well I don't want to make it THAT easy to logon as
another user.

Just want to gather some opinions.



PHP Database Mailing List (
To unsubscribe, visit:

PHP Database Mailing List (
To unsubscribe, visit:

Reply via email to