Please correct me if the following is wrong.

Being the parent table in a relation means that (generally) changes to the parent's pointer automatically cause the child's pointer to track to the child record whose keyfield 'relates', in a specified way, to the correspinding keyfield in the parent record. It gets a little more complicated if the relation is one-to-many, but the underlying fact remains that modifying the parent table pointer causes VFP to make a corresponding change to the child table pointer, but the reverse is not true: explicitly changing the child table pointer does not effect the parent pointer.

Aside from needing a prescription for exactly how a change in the parent table pointer effects the child table pointer, the above paragraph completely encompasses the nature of the parent/child relationship...it's based on pointer synchronization.

True or False?

I ask this because the use of the terms parent/child had me a little confused about how relations work. I had thought that the 'parent' was always a table, such as a customer table, with everthing you wanted to know about each customer. In this parent, each customer would have a unique ID number that could be referred to by other 'child' tables so that these other tables wouldn't have to repeat all of the information and thereby reap the bitter fruit of redundant data.

In fact, the tech manual's description for SET RELATION uses just such an example. Fine. The parent table has all the genes and the children express them by referring to them with a code. And this works fine if the child is ordered according to the relation key because the situation calls for the child to be processed in that order.

However, when I started working and trying to understand a DOS based FP app to upgrade it, the original developer used relations in just the opposite way.

The parent table was, in this case, a work order table, ordered by work order number and the child was the customer table related to the parent through the customer number. In this case, it's the lookup table ... having all of the information...that's the child. The child has the genes and they're referenced by the parent.

The intent in this case is to be able to process the records according to work order number (because the situation calls for it) but still have instant access to the customer information related to the selected work order. Seems like a completely reasonable thing to do.

But it reverses the parent/child concept with respect to the example given in the tech manual(and totally trashes my intuitive understanding of how the parent/child analogy applies to database tables and relations) . And naturally, triggers some questions.

Is the way my developer friend used relations somewhat unconventional? Was there a more accepted way of achieving the look-up result he wanted in the pre SQL-SELECT/JOIN days? Or has it always been generally true in DB theory that the parent/child analogy was coined to describe the table pointer synchronization relationship and not really applicable to which table is the dictionary?

(PS. I'm sure some of you SQL-SELECT weenies out there are saying, 'who cares, use JOINs'. Well, you're probably right. Still, I'd like to understand the concepts behind the old app I'm tasked to upgrade so I'm clear about its behavior...and I'm curious generally)