NYCPHP Meetup

[tedd]

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/