Re: Normalization, Natural Keys, Surrogate Keys
Date: 16 May 2002 22:32:10 -0500
Message-ID: <uit5n9t61.fsf_at_rcn.com>
On Fri, 17 May 2002, comedyharris_at_hotmail.com wrote:
> 1. By making the parent id a foreign key, it seems like you're losing
> information in the design. More specifically, a child is related to a
> parent, but not dependent on it for it's existance. So here, the
> business requirements are not well comunicated through the design?
I'm don't understand how this is different with natural keys?
> 2. Everywhere I go people are trading off performance over everything
> else. Ok, I admit I'm a little touchy on the subject, but 2 of your 3
> points were directly related to performance. In my limited experience,
> I've seen more projects fail due to 'understandability' than
> performance.
customer_tbl.cust_id = address_tbl.cust_id.
Need to see some of the account stuff?
customer_tbl.cust_id = account.cust_id
> 3. Hymns in database discussion groups. Now that's definately
> violating some integrity consraints!?
>
> I'm keen to learn more, so how can your 'surrogate key' version
> communicate the same thing as a composite primary key? I now have to
> examine the parent/buesiness rules to realise what it's 'real ' key
> is, since you've replaced it with a surrogate key. BTW, I'm not going
> to argue about the performance issues, although database vendors could
> probably create their own surrogate keys internally to replace the
> composite key.
I would assume most do, but they would still need to store the uniqueness criteria as well.
-- Galen deForest Boyer Sweet dreams and flying machines in pieces on the ground.Received on Fri May 17 2002 - 05:32:10 CEST