Jim,

>>Here you are shifting the problem. If the table has another intelligent key (articleno) you'll still have to check for uniqueness, which IMO is best done with the help of a filtered candidate key.
>
>No I am not "shifting" the problem. I am eliminating the problem from the Relational issues and moving it to the business issues. Business issues do not effect the integrity of the system, they may effect the accuracy of the system. If the systems integrity is intact then the accuracy can be fixed. I simply choose NOT to expose the system integrity components to human intervention thus making the insurance of systme integrity easier and more robust.

We seem to have different interpretations on this. I do regard a unique constraint as a part of the RM, you don't. May I ask how you would enforce this business rule ??


>>My question is, what will you do when you're asked to develop a VFP application for an existing DBMS (let's say ORACLE) which uses intelligent keys for some tables which you want to download into a VFP database ?
>
>Existing systems are outside of my direct control. I am responding to the issue of choosing one way over another. In an existing system I don't have that choice because the system already exists and has already been configured using one or the other system. I can ask you the same question, if you come across a system that uses surrogates exclusively will you change it to use natural keys in certain tables or work with it the way it is?

I don't reject the use of generated keys, I reject the forced use of generated keys in all situations. Therefore I'll not have any problem in maintaining or enhancing that system. Situations where generated PKs are not possible (History Problem, PKs on ranges) the problem does not occur because they can't be solved with generated PKs (nor relational theory).


Walter,