Re: Surrogate Key vs Production Key

Galen Boyer <galenboyer_at_hotpop.com> wrote in message news:<u4qkjx8si.fsf_at_standardandpoors.com>...

> >>
> >> Here's my stab,
> >>

Yup, very much agree with all you said.

>
> Based on the market, we would subtype the loan table and give out
> something like, cmbs_loan, and on that loan table we would put
> the "natural key" for searching and uniqueness.

Bingo!

> > That isn't a surrogate key any longer, as far as I can
> > tell. End Users never see the surogate keys.

Oh yes it is. System generated. And calling it "loan_ID" doesn't mean it is what the user sees. It's all in the naming convention. ;)

> > Also, this doesn't sound flexible at all. If there are three
> > loan type, you are building three loan applications.
>
> We have one application, multiple subtypes.

Exactly! And if tomorrow, some moron in marketing finds another way to snag customers and asks you to add another "loan product", it's no sweat off your back, is it? In fact, you can add it as another entity/table or as a column selector. Without having to do aything to any logically dependent entities, or updating any FKs. Now, ain't that what one would call flexible?

Of course I'm over-simplifying here a bit. It would need to be done with care to make sure there wouldn't be missed dependencies. But you got the core of it, in one. Received on Tue Oct 26 2004 - 06:46:21 CDT