Walter,

You knew I would reply didn't you :-)?

>PROBLEM 1.
>Let's say that we've got an article table wherein the articleno logically is the primary key.

In the case of relational design only the primary key is required to be totally unique. Once a surrogate is used the alternate becomes an issue of business rules and can easily be handled outside of the database in the business rules. It is not necessary to use a candidate index to enforce the uniqueness of the alternate key. However, in VFP it IS necessary to use the Primary index for the use of referential integrity as persistent relations MUST originate from a Primary Index.


>PROBLEM 2.
>
>Lets say we have got articles and clients and each client can have custom prices for each article. Then we would make a ArticleClientPrices table with the following structure:
>

As long as no future enhancedment creates a child to this table you are right. However, once a child is born then the compound key is propagated and the trouble begins. Also, during the normalization process a single attribute PK only requires the first 4 normal forms while a key of two attributes requires 5 and three or more attributes requires all 6 rules be applied. Using the surrogate makes normalization an easier process and allows for easier future expanmsion of the database.


>PROBLEM 3.
>
>In most cases our records are adressed based on a single value identifier. However there are cases where the PK actually is a range of values. Let's take the following example:
>
>The number of vacationhours of an employee is determined by it's age. Therefore the following table exists:

Again, the same answert as problem 2. Take this example;

Joe has vacation calculated based on his Startdate. Then the record that was used to do the calculation is changed because the ending date needs to be brought backwards. This causes Joes vacation calc to change. How do you find the original record that was used to calc Joes vacation? The date range has changed so it can't be found using the dates, that would find the new record that applies. If a surrogate was used then it would be easy as Joes vacation record would ahve the surrogate key for the vacation clac record and it could be found, then once that was done the calc could be reversed and the new record found based on the dates.

Also, a major reason (for me) is that consistency is more important than saving space (unless space becomes a demonstrated problem). Therefore if one table has a surrogate key then I want all tables to have a surrogate key. This removes the need to keep track of which tables have surrogates and which do not. It also means that NO Primary index has a filter on deleted and it prevents the need for a second index on the PK for the use of Rushmore (it won't use a filterd index).