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

>> 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.

>> "Surrogate" keys as you define them strike me as vile. <<

That is not me; that is Dr. Codd. And they are no more vile than an index on a table -- they are an index between tables, such as you find in Sybase and Informix and Teradata.

>> We just use "exposed" keys exclusively. I haven't found it to be
any particular source of problems, but perhaps, if there *were* a reality being referred to, there would be problems. <<

Exposed physical locators are like pointers, so this is a LISP application.

>> 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.

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. Received on Tue Oct 19 2004 - 04:59:37 CEST