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

OK, first name and last name will be unique..
A day goes by...
Oh shit...OK, I'll try first name + last name + city
Another day goes by...
Oh shit... Ok, I'll try first name + last name + city + state.
Another day..
Oh shit.... and you get the idea....

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.

There is a big difference between a Key - such as an account number - and a Primary Key - best created through a generator - that is used to enforce referential integrity...


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

>It's up to you to decide which way to go. I've found that many prominent developers up here tend to use generated PKs. For myself i'm quite comfortable with using 'intelligent' keys. I see benefits to both, but I think you'll need to be consistent. If you choose for one, you should stick with it for the whole app or project.
>

Yes, consistiency is good....

>When using generated PK's it sure is wise to label the intelligent key as a candidate key to prevent multiple instances of the acctno (again you'll have to filter this one on DELETED())
>

Yes, if the other key needs to be unique, it should be a candidate key.... We agree here...