John,

>>- when using generated PKs, it will be more difficult to 'read' the child tables because now they have a meaningless number instead of for example a Acctno number making it somewhat more difficult to debug or doing thing under the hood.

>It really should not be difficult at all. A PK is a relational DB mechansim only... It is something used by the system, not by an end-user directly. Generated/surrogate keys are far better than keys over which the user has control. When folks try to do things, like combinations of fields, it usually goes like this:

Many people think this is the best way including DATE. Me for myself am quite comforatble with intelligent keys. There is no hard written rule you may NOT use intelligent keys. In fact they specially have invented the Cascading update for these purposes.

>OK, first name and last name will be unique..

I agree, when using composite keys it may be doubtfull. But when using a personelnumber (integer), i don't have many problems with it. Also when using a short Articleno, i don't see many problems either.

>Somthing like an account number is fine as a candidate key - something an end-user or a customer - say a bank customer who needs to refer to his/her bank account number - needs to refer to. Yes, it is a unique number. However, as a PK - to use something like an account number as a basis of a relationship between database entities - is not correct.

Depends on the entity.


>>- When reporting it's likely to occur that you need more relations (xBase way) or JOINS (in SQL) to collect the other (candidate) key of the parent table for inclusion in the report, decreasing performance.

>Once again... you keep harping on this performance issue with SQL vs. xBase. In almost all of your posts, you make this the rule, as opposed to the exception. On the contrary, SQL is a far better mechansim... It is quite popular - and for good reason - it performs well. If it did not, nobody would use it...right??

John, your personal feelings against me affects your reading ability. If you would read this statement carefully and think about it I didn't compare XBase Relations with SQL. I was just saying because you don't use intelligent keys, you've got set up a relation or a join to pick up the candidate key for reporting purposes.

Since you won't (try) to believe when I'll say that the relation will be faster than the join (embedded SQL), I'll not respond to anything you say reading this subject.

Walter,