Re: Stupid Database Tricks

From: DBMS_Plumber <paul_geoffrey_brown_at_yahoo.com>
Date: 23 May 2007 11:27:55 -0700
Message-ID: <1179944875.130572.241020_at_h2g2000hsg.googlegroups.com>



On May 23, 8:27 am, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
> Allow me to suggest why it drives folks crazy: it represents a complete
> abdication of thought. As such, one cannot use reason to reach those who
> espouse it because that too requires thought.

Let me go on the record as supporting Bob's sentiment here 100%.

And I'll up the ante by bashing the hand that feeds me. The way foreign keys are implemented in SQL DBMS products is really suboptimal.  Currently, if you declare a table to have a compound primary key, and then foreign keys from that primary key, the DBMS will store the 'value' of the key / FK attributes multiple times: once for the keyed table, probably multiple times for each of the dependent tables.

In hindsight, a much more sensible approach would have been to use the underlying physical properties of the record store to maintain the relationship. A set of 'key' attributes values needs only to be stored and indexed once with physical access handled as it is currently.

>From a logical point of view, nothing changes. But taking this
approach would remove a lot of the physical efficiency arguments DBA's typically use to justify system generated surrogate keys.

Oh well. Mebbe we'll get around to making this change one day. Received on Wed May 23 2007 - 20:27:55 CEST

Original text of this message