>>>>On the other hand, relationships between tables will be a lot simpler if you store the Primary key in a single field.
>>
>>>I may be biased, but I like working with composite keys. In your example, how do you established the foreign keys once you have merged two fields into one ?
>
>>Just as with a composite key: with the REPLACE command. With a single field, you need a single REPLACE command instead of two.
>
>I am confused now. When I am talking about establishing foreign keys, I expect to set indexes and relationships so that the VFP database will reject any attempt to enter in the child table a value which doesn't exist in the parent table. I mean, the data integrity must be enforced by the database itself and not by the code. What does this have to do with the REPLACE command ?
I thought you were referring to inserting the value in the child table.
To enforce the relationships, just use the referential integrity builder that comes with VFP, or an alternative RI-builder.
Whether you use primary keys made up of a single field or composite keys, the relationship is from one index to another index. It works exactly the same way.
Difference in opinions hath cost many millions of lives: for instance, whether flesh be bread, or bread be flesh; whether whistling be a vice or a virtue; whether it be better to kiss a post, or throw it into the fire... (from Gulliver's Travels)