Re: Primary vs. Surrogate! What a nightmare debate.

"--CELKO--" <jcelko212_at_earthlink.net> wrote in message news:18c7b3c2.0410181859.4cf9bfd6_at_posting.google.com...
> >> In the kinds of applications I work in, "natural" and "artificial"
> keys are an impossibility; we create data structures, and there simply
> is no corresponding reality to reference. <<
>
> I don't understand "create data structures" -- are you using SQL to
> program in LISP? That is the one language I can think of which has
> nothing but structrues in it.

Ack! No lisp involved!

We don't sell any physical goods, is all I'm saying. We sell a service, but it's not physical either; no technician comes to your door. You send us money and we do stuff with our database. So there's nothing in the physical world for us to use a source of natural keys, unless maybe we were to hash what the customer sends us.

> >> "Surrogate" keys as you define them strike me as vile. <<
>
> That is not me; that is Dr. Codd.

Six of one. :-)

> >> I find it quite interesting at times to what a surprisingly great
> degree the specifics of the application domain influence the value of
> particular design choices. <<
>
> That is not a surpise to me. The problem domain ought to be a big
> part of the solution.

It makes sense when you put it like that, but I still get surprised.

> I get surprised at how often I see an old technic get re-invented in a
> new technology, even when thre are better ways to do a job. Today
> there was a guy in the SQL Server newsgroup asking about how to manage
> queues when they get extra processors. He has been using tables for a
> single queue until now. I had flashbacks to IBM OS/360.

Marshall Received on Tue Oct 19 2004 - 01:17:42 CDT