Probably a better question than the use of identity columns versus compound keys ( or natural versus surrogate keys ) or ( intelligent versus dumb keys ) is the following:

Considering that a database created today will probably not remain a silo for long, and will require integration with other data sources as a matter of course, what is the best paradigm for creating a physical primary key?

Should it be generated by something external to the database ( as a GUID in SQL Server can cause hotspots ), or should you rely on the integral ability of SQL Server to keep identities unique (at least in each individual database)?

The answer seems to logically flow towards a globally unique key of some sort, to keep it as short as possible, and also to contain no intelligence, as the idea is to use this key internally (not for human use).

I'd be intersted to hear how enterprise database designers are dealing with this issue...

regards,
frankg