John:

> Please give me an instance where the use of surrogate PK's hurts you...
>
> There is a big difference between considering alternatives and choosing to
> always use surrogate keys. I for one always have an eye out for FEASIBLE
> alternatives. Choosing to not use surrogate PK's is an immutable rule for me.
> It is like the naming conventions I use or the way I handle RI, or the way I
> handle parent/child relationships. I have a few rules that I ALWAYS use.
>
> Of course, if I encounter a situation where an immutable rule does not apply,
> I guess it ceases to be an immutable rule. And, this has happened before.
> That cannot be said for surrogate PK's.

See Message #459506 for an example where the use of surrogate PKs hurts complexity of reports. I only listed the worst case but there are 100+
reports for which complexity would have suffered with use of surrogate keys
in all tables.

> One thing to keep in mind in answering the question above. You can't answer
> it from the perspective of the benefit that a natural PK gives you. You have
> to answer it from the perspective of how the use of surrogates directly hurts
> your app or design...

Yes I can. You seem to favor the Apply the general case unless it hurts
you philosophy while I prefer the If a special condition exists,
consider the alternatives; otherwise apply the general case philosophy.
I am a natural (pun intended) Devil's Advocate and I seriously doubt someone
could make change philosophy.

Daniel