At 6:46 PM -0500 3/6/11, David Krings wrote:
On 3/6/2011 3:46 PM, tedd wrote:
You won't have any "redundant" info if you use email as unique -- after all,
email *IS* unique.
Unique yes, but it can change.
If that is the case, then change it -- I don't see a problem. I do
see a problem IF one wants to keep both email addresses as indexes
for that record. An index must be unique.
The main point here is that you must have a unique identifier for
each record. Some way to access *that* record. You may choose
anything you wish -- such as: email address, social security number,
time of record entry with a random extension, or an auto-increment
id. The choice is yours, but the final choice should be unique. You
must be able to find the record without ambiguity.
----
You'd need to change the primary key of a record if a user wants to
use a different email address.
No, you are misunderstanding what a "primary key of a record" of a
record is -- it is simply unique. As said before, it can be anything
you want provided that it is unique.
----
Not sure if that is a smart thing to do. You'd need to update all
related records, which wouldn't be necessary when using an integer
as primary key that is only data and not information.
You are misunderstanding the process. There is no "update [of] all
related records" -- you are simply changing a single record. That
record contains all data necessary for that record including all keys
to remote tables -- there is *NO* reason to change any remote key.
----
As far as normalization goes, I represented it the way it was once
explained to me, which I do not insist on being correct. In any
case, I think I got the point across of the practical benefit of not
splitting up related data across multiple tables. There are many
ways to do it and some say it is right to do it that way, others say
it is better to do it this way. In my experience the approach I
detailed is what works for us best for an enterprise product. Of
course, Celko probably calls us all idiots and has a totally
different opinion on how to do things.
Normalization of a database is simply moving redundant data to remote
tables and replacing that data with remote keys to those tables, as I
demonstrated in my last post.
People can often over-think this process. but it is a very simple concept.
Cheers,
tedd
--
-------
http://sperling.com/
_______________________________________________
New York PHP Users Group Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
http://www.nyphp.org/Show-Participation
