Re: candidate keys in abstract parent relations

Tony Rogerson wrote:

> But don't forget there is another phase after the logical model and thats
> the implementation of it.
>
> This is where surrogate keys really come into play.
>
> It helps create a highly scalable database and provides an efficient
> interface into the applications using the database.
>

Absolutely. I didn't anywhere mean to imply that surrogate keys (artificial or otherwise) are unnecessary in the implementation. I was simply trying to explode the idea that "I don't have a key so I need to create an artificial one". That fallacy is the cause of much bad design. A key is not a surrogate unless it has a corresponding natural key.

> a lot of designers
> (especially celko) try to directly implement the logical model without
> regard for anything other than writing pure SQL against it. The database
> from a business stand point is there to store data.
>

The problem is that many (perhaps most) SQL DBMSs are somehwat limited in the options they support for abstracting the logical model from its physical implementation. This is unfortunate and it is the reason why we have to make so many design compromises. I do agree that those compromises are necessary in many cases but that doesn't mean the theory is inadequate - it means the products are.

-- 
David Portas