Craig,

>>Well, I've had some heavy discussion with JIMB about this subject. And I respectfully disagree with this statment. Though I know CODD or DATA do discourage intelligent key's, they're part of the relational model.
>
>Yes, I've followed those discussions.

Hmmm. We finnaly got the feeling noone was listening. I'm glad at least someone did.

>I have intelligent keys in my table...they are candidate keys. I agree, debugging using intelligent keys makes things a bit easier. I've done development both ways and found that the advantages of surrogate keys outweighs their drawbacks.

What advantages do you experience ?

>There may be a couple of occassions that would require fewer joins, but not very many. Again, IMO, the benefits of a surrogate PK outweigh its disadvantages.

Within a major project of mine, that would very many.

>>Using generated PK does remind me of the hierachical databases with pointers to child records. I'd really don't want to go that way.
>
>Even with intelligent keys and normalization, you still need child tables. Using surrogate keys does not limit me in any way.

I was refering to the fact that a hierarchical database was/is using meaningless pointers to connect parent and child tables. This generated PK thing does remind me of this.

>>In many cases I might use a generated key, but not in all. For Example if I got a article table, i would choose articlno (character) as the PK.

>I would have an article id too, but it would not be the PK. It sounds like something that is user entered and/or generated based on the data.

Well, I guess we have different standpoints on this. Because you've followed my discussion with JimB it seems pointless to start over again.

Walter,