It is not redundant, not having a primary key keeps the door closed to a lot of things. Even for basic functions, the database works off of an indexed primary key much faster than a varchar value floating in a tables values.
Expansibility wise it is also a good idea. Primary keys make everything easy and fast to reference, you can also change anything else on the row without a problem.
Once again, its simply good practice to put a primary key in. Now it is not required, but being able to run does not make an application good.
Even for basic functions, the database works off of an indexed primary key much faster than a varchar value floating in a tables values.
True, but there's no reason why that indexed primary key absolutely must be an auto-incrementing integer type.
For the particular situation of this topic, using an email address as the PK isn't a problem unless there are plans in the future to expand the system (but we can worry about that down the line, right? right?). The email address field (PK or not) will have to be indexed (unique) anyway to save repeated entries and keep the lookups speedy (e.g. when collating the addresses to send out).
All that said, there's good reason why using an integer auto-incrementing primary key is so common and it's a healthy habit to fall into.
Let's say you want to advance this project later, to have permissions and access levels. So you have a usergroup, that user with emailid 'email@example.com' is a member of, lets him login on your site with his email and manage some things on list as an administrator.
Then he changes his email, woopsie, you have to manually change this cause there's noone with the emailid of 'firstname.lastname@example.org'.
Thus, an emailid as a numeric, and keeping the actual email in another field, is the better solution, as I said; It will open more doors for future use.
Tanax I dont get that example, why would he have to do it manually? It could all be done automatically with minimal performance loss.
I can argue against that because now you have a numerical id, and therfore HAVE to make a join to the master table to make sense out of that numerical ID. And usually when I have to create a table which will reference another table then it usually done with GUID rather then int. I've found auto increment giving me a lot of problems before (espeically with duplicating, deleting etc etc)
Village Idiot, I didn't say not to have a primary key. And theres not really that much of a difference between an int and char primary key. In most cases it actually makes things easier.