(< sigh > yes, I know better than to jump into this discussion but we've gone beyond the top edge of wading boots so it's time to wring out some muddy water methinks)

> Untill about a few years ago everyone used intelligent keys.

ROFL... sorry Walter, but as usual there seems to be Standard Relational Database Theory, and then there's Walter's Relational Database Theory. (for those who dont remember see past discussions between Walter and JimB, and have a beer or two handy to get thru huge time & bandwidth waste)

I first heard/learned/studied/implemented surrogate keys in a tech school course in 1990; the textbook was what is STILL the de facto standard text for relational database theory: Handbook of Relational Database Design by Fleming and Van Halen, ISBN: 0201114348 (I say this defacto because 5 years after this tech schoool, I had the exact same book in a college course on relational database theory, and everytime you look at recommemded resources for the same topic, this book comes up - still, and it was published over twelve years ago, therefore we're well beyond the 'just a few years old' window here Walter, in fact it's old news... where have you been?)

>I've got a real problem with strict following methodologies. each methodology has its value that it describes the global guideline on which you can reach your goal.

IMHO, "Methodologies" are the practices you use to produce work while a "Theory" is a proven set rules to manage a process. I've always heard of handling relational databases as "relational database theory" and NOT a methodology... maybe that's why you alway seem to make these discussions seem like your mixing apples & oranges (your way vs. the standard way). Perhaps 'metholodogy' and 'theory' is the same thing... who knows, and I dont really care because as far as I'm concerned, in my 12 years of building/maintaining/designing database applications I have never seen a good reason not to use surrogate keys, and have always suffered downfalls/shortcomings/problems with intelligent keys... all of which I have always been able to resolve with using surrogate keys. And no, I can't say I've experienced the same sort of downsides with surrogate keys, sorry... the only good reason I see to ever use intelligent keys in a database application is to show how little you know about standard relational database theory.