Re: Normalization, Natural Keys, Surrogate Keys

In message <c1ec9b8f.0205300726.545506cd_at_posting.google.com>, Kai Ponte <cybermusicdude_at_aol.com> writes
>Bernard Peek <bap_at_shrdlu.com> wrote in message
>news:<tFi0JoKoDV98EwUU_at_shrdlu.com>...
>> In message <c1ec9b8f.0205290820.706424bc_at_posting.google.com>, Kai Ponte
>
>> I would probably also drop the RowID column because it adds complexity
>> without adding functionality. The compound key created from the SSN and
>> Error columns is small enough that it wouldn't create any real
>> performance problems.
>
>See, I always hated those compound keys. I like to keep things simple

"Make things as simple as possible, but no simpler" -- A. Einstein

>and I believe just the opposite - having RowID as my primary key for
>every table is much more simple and removes complexity. Having one of
>those compund keys that you always read about in the DBMS manuals and
>textbooks is too complex for my simple brain.

It's simpler, and it removes some complexity but adds it back in elsewhere. You need to check to make sure that the real key and the RowID are kept in sync. Provided you do that the RowID is a perfectly usable key.

>
>It is funny, acutally. I took four classes in database design and
>management while doing my MBA in the early 90's. I never could see
>why I wasn't comfortable with the theories of using compound primary
>keys. Once I started using RowID as my primary key, my database
>designs became much cleaner and easier.

I think that's because it hides some of the issues that the designer really needs to look at. The table still needs a primary key, RowIDs are not the same thing and aren't an acceptable substitute for them.

-- 
Bernard Peek
bap_at_shrdlu.com

In search of cognoscenti