Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Surrogate Key vs Production Key

Re: Surrogate Key vs Production Key

From: Noons <wizofoz2k_at_yahoo.com.au>
Date: 13 Oct 2004 04:18:55 -0700
Message-ID: <73e20c6c.0410130318.338eae78@posting.google.com>


ats <damorgan_at_x.washington.edu> wrote in message news:<1097550985.913694_at_yasure>...

> > Name ONE commercial application that uses natural keys
> > instead of surrogate keys.
>
> You mean you want to fall back on those high quality applications
> like Siebel, SAP, Baan, and PeopleSoft to define good design? Oh
> please.

I repeat: name ONE commercial application that uses natural keys instead of surrogate keys.

Why on earth do you think there are none? Because YOU are right and everybody else is wrong?

> If you want to bring RAC into it there is a definite point in
> favour of using natural keys as RAC has a known issue with using
> sequences: Though there are workarounds.

Exactly. And what Oracle is doing now is spreading the misdirected, misinformed and false assertion that surrogate keys are somehow "bad", to hide the simple fact that RAC can't handle them properly.

Which will have exactly the same result as the "bind variable" wars of 5 years ago: everyone listened and couldn't do anything about. Oracle finally had to implement a fix with the well known parameter we all know about.

Took a while, but they finally understood that they can blame dbas out there as much as they want for the "bad design" of third party apps, it ain't gonna change one bit what the market is doing: they were chasing the WRONG people, for the wrong reasons. I already repeatedly stated the same here on this particular subject. Watch the 'proceedings' from now on: as usual Oracle chases the wrong people for the wrong reasons.

Not because there is anything wrong with bind variables, or natural keys. But no one in this industry in his right mind is gonna start designing for one single particular enviroment and implementation. And Oracle was unique in all relational databases in requiring people to use bind variables and now requiring people to use natural keys (all of a "sudden").

WHY is it that THEIR OWN apps do NOT use natural keys? Hmmm? "poor design"? in a pig's arse!

> customers may or may not do. But that doesn't mean all of those
> marvelous products don't have large quantities of data that a
> sensible person would deem integrity-challenged.

They don't. There is NOTHING with surrogate keys that compromises integrity. That is as FALSE an assertion as can be.

> I clearly stated that I have never. I means me, personally.

I wasn't replying to you.

> I don't use natural keys when I can't. I don't use surrogate keys
> when natural keys make sense. And I don't get emotional about it
> either way.

And if you think I get emotional, then you are even more mistaken. Received on Wed Oct 13 2004 - 06:18:55 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US