Roxanne,

>(< 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)

Somewhere in the beginning of the 90's Chris Date has released a version (5th edition ?) of his introduction to relational database system in which to my knowledge all the examples are done with intelligent keys. I've used this book as a source for my graduation. FYI, this discussion is needed to get some clear and good info regarding this subject. Before I started these discussion there was nothing more said than: "Use surrogate keys, they will solve your problems" while this assumption was 100% incorrect. I want to come to a conclusion after this discussion to which everyone agrees. That conlusion should be simular to the conclusions made in the whole DB world. I personally do make a case for intelligent keys, though I'm certainly convinced the surrogate keys are better in the majority of cases (as I repeatedly have stated here).

However in this thread at least someone agrees (ErikM) that there are difference between approaches in which intelligent keys do have an advantage (as known for a long time in the whole DB world, but somehow not in the VFP one). There where there are two difference approaches with both advantages and disadvantages there are cases which ask for a certain strategy.

In the reply to this statement, it was noted, that for 'consistency' reasons one chooses for the forced use of surrogate keys. Now this sounds a whole lot different than surrogate keys are always better than intelligent ones.

>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?)

In fact at that time, I knew nothing about relational databases.

>>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.

Theory, sure isn't always proven. Noone has proven the greenhouse effect yet.

>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).

That's my point. There is NO standard way. There are too many differences between Chris Date, Codd and Joe Celko and others.

>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.

There is no need to get rude here. Tell me what 'standard' relation database theory is suposed to be. You can easely dismiss my knowledge of the RDT becuase i'm not an authority. Just ask Joe celko, and he will show you how little you know about relational database theory.

Whether you like it or not. The choice between surrogate keys and intelligent keys may have little impact on the relational database theory itself, rather
than it is interpretated.

Walter,