I completely agree with you, we use surrogate keys in ALL our tables.
We have things such:
Table Product(ProductID integer,
ProductCode varchar(50),
Description varchar(100),
....
)
The PrimaryKey is ProductID so in other tables like Order_Detail,
Sales_Item we just use the ProductID, if the customer wish to change the
ProductCode, nothing happens to the child records, nothing changes....

And as you have said, we could use some VERY generic routines (or better
objects) that references the Primary Key in a generic fashion.

So we have an Ancestor Class that has methods to seek, update, delete, and
things like that based on TableNameID as Primary Keys, this kind of
generalization help us a lot...

Alexandre Benson Smith
Development
THOR Software e Comercial Ltda.
Santo Andre - SP - Brazil
www.thorsoftware.com.br

P.S. Sorry for my poor English.

At 17:51 03/01/02 -0500, you wrote:

>At 01/03/2002 05:39 PM (Thursday), sugi wrote:
> >At this point I cannot decide which approach is 'better'. The major
> >complaints people are having with the surrogate model is that it's
> >'unusual'. Opinions/suggestions/tips or even links to appropriate
> >'reading materials' will be greatly appreciated. Many thanks in advance.
> >
> >Salam,
> >sugi.
> >
> >PS : I guess this can be the tip of the iceberg for bigger question,
> >like "is surrogate keys ALWAYS a good idea ?".
>
>I happen to think what you call surrogate keys are always a good idea.
>Using primary keys based on application domain data values is always risky.
>Users have a tendency to change those important values and then you are
>faced with an annoying task of handling primary key changes which otherwise
>would not be required. Using surrogate keys also helps keep index records
>smaller.
>
>We have recently built a system which uses surrogate keys extensively, all
>of which are generated. One really nice by-product is that you can uniquely
>identify any single record in the database by a combination of table name
>and a single integer ID value. In the application code we call this a
>"record reference" and pass them around as objects. Very slick. Allows you
>to write some very generic code.
>
>
>
>
>To unsubscribe from this group, send an email to:
>ib-support-unsubscribe@egroups.com
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/