Re: Surrogate Key vs Production Key

wizofoz2k_at_yahoo.com.au (Noons) wrote in message news:<73e20c6c.0410081904.635ceb51_at_posting.google.com>...
> ed.prochak_at_magicinterface.com (Ed prochak) wrote in message news:<4b5394b2.0410081003.1a57317f_at_posting.google.com>...
> >
> > really? Zero problems?
> >
> > just wait until you get ONE bug into the production system with
> > surrogate keys and all hell break loose. Or a conversion from such a
> > system where the dump program has a bug.
>
> I don't understand. Are you suggesting that surrogate keys
> are buggy or that only surrogate key systems have bugs?

If you have a bug and it corrupts values in the child table, you may have no way to restore those child records back to the proper parent. Why because that is not relationship between the Surrogate key value and the data it is supposed to connect. It is often just a value selected from a sequence. So changing the FK value from 1000 to 10001 just changed the parent from john smith to abby hutchison. But a bug in a natural key which changed john smith to john smithe might be correctable.  

> Because if you are either of them, then let's talk bridges indeed.

You made the ZERO claim for surrogate keys, I made no such claim for natural keys. My only contention is that it is a lot harder to recover from a problem when the surrogate key values get screwed up.
>
>
> > All a surrogate key does is convert a relational model database into a
> > network model database.
>
> That is an impossibility.

The Surrogate keys are not part of the real data, they are a ficticious relaionship. Logically the SK's are just POINTERS. That make it logically a network model, IMHO.

>
>
> > I've done it both ways. Both work, but both also have their problems.
>
> Still waiting to hear of one with SKs.

Then you haven't been listening. Received on Wed Oct 13 2004 - 13:31:40 CDT