Luco,

More often now you read articles about using "meaningless" keys. They are generally smaller 4 bytes gives you 2 gigabyte key values. They allow the human readble items that would have been used as keys to more easily change over time. They are internal use only, the user never ever sees them.

The relational model doesn't dictate that you have to use compound keys, and in Xbase they've pretty much been a pain to work with as systems change. Say you have a compound key of itemno+date so you create the relational link, making sure that SET EXACT is off otherwise the partial string match doesn't work, easy enough... but now the client wants to see the child data in a different order, maybe by reverse date or by some other field. So you have to create a new index to support this and change your code. With meaningless keys all you have to do is change the ORDER BY clause of the parameterized view, no other code would need to be changed.

Also the referential integrity code that VFP generates doesn't work with compound keys.

>I'm suprised that people in the vfp environment belief in another way implementing tables with compound keys.
>
>From my school experience making a compound key was the only right way according
>to the entity relation rules.
>
>I have to study your way what more before I will implement it in my programs.
>But I think that your experience with database designing is much bigger than mine. So I serious have to think about doing it the other way.