Re: Surrogate Key vs Production Key

Comments in-line.

Noons wrote:

> Daniel Morgan <damorgan_at_x.washington.edu> wrote in message news:<1097431960.682256_at_yasure>...
>

>>>Arguments, you want?  Already supplied a few.  Here is more:
>>
>>I don't think you truly have an argument as I can not think of a single
>>time in the last 5 years I have found a reason to update (modify) a
>>natural key. I think you've been eating too much red herring ... try
>>salmon instead.

You mean you want to fall back on those high quality applications like Siebel, SAP, Baan, and PeopleSoft to define good design? Oh please.

> Now, you may choose to ignore the vast majority
> of the IT market. For the sake of hiding the problem
> Oracle has with sequences in RAC.

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.

But yes I will ignore the vast majority of the IT market because what I've seen of most of it is junk. Surrogate keys are easy. Surrogate keys are simple. Surrogate keys make sense selling a product as you don't have to concern yourself with what your 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.

> But you are doing that on your own. Just don't give me the
> bullshit about "have never found that anywhere".
> You know perfectly well it is not true.

I clearly stated that I have never. I means me, personally. It does not refer to you or anyone else or their experience. But then 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.

-- 
Daniel A. Morgan
University of Washington
damorgan_at_x.washington.edu
(replace 'x' with 'u' to respond)