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

>
>Personally I've got a few reasons to use intelligent key,s:
>- It makes raw tables much easier to read, especially when testing or debugging applications.
>- It generally requires less joins (as the intelligent key is only in one table) in your apps, therefore improving performance. The same reasoning goes for denormalization.

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.

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.

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

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

>
>Walter,