Re: Surrogate Key vs Production Key

wizofoz2k_at_yahoo.com.au (Noons) wrote in message news:<73e20c6c.0410080449.50e0a1fd_at_posting.google.com>...
> Daniel Morgan <damorgan_at_x.washington.edu> wrote in message news:<1097210055.635712_at_yasure>...
>
> > Joe Celko weighs in on the side of natural keys and so do I.
> >
>
> Joe never had a client walk in and say:
>
> "you know that code of 'A/0001/sdkjskldjklsd-32998'?
> Shewt!: we mistyped it.
> Can you change it to 'A-0001/sdkjskldjklsd/32998'?
> "
>
> and suddenly he realizes that natural key is now duplicated
> in a 6 level hierarchy of tables as a FK in thousands
> of rows. Which means a major UPDATE on all those tables
> with all RI disabled. Count the downtime.
>
> Zero problem with surrogates. I'll take that anytime.
> For the cost of an extra index. Because I still have to
> see a natural key that somewhere, somehow, doesn't get
> mistyped.
>
> Errare humanum est...
> To really stuff things up, you need a natural key.

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.

All a surrogate key does is convert a relational model database into a network model database. Except if you used a real network model database, then the DBMS would manage the surrogates instead of your application code and likely the surrogate key would be a direct pointer so the performance would be even faster than your relational implementation.

I've done it both ways. Both work, but both also have their problems.  ed

If you still believe the Zero problems,
then I'd like to talk to you off line about  this great deal on a bridge. 8^) Received on Fri Oct 08 2004 - 13:03:00 CDT