>An even better approach would be a single, self related table called People. With a setup like this, a single table holds all common information, so you can also find out the mother's criminal record, and the children's bra sizes. So getting an entire family tree could be done with a query like this:
>
>Select Person.Name, Mother.Name AS MotherName, BraSize, CrimHist, Age ;
>FROM Person, Person Mother ;
>WHERE Person.MotherID = Mother.ID
>

You anticipated my next question perfectly, but I'm not sure I understand exactly how your example above would be implemented.

My next question was going to be how one would address the more generalized problem of specifying all of the familial relations for anyone from the domain of say (let's be ambitious) all known people, living and dead. As I understand it, your big self-related table would consist of a single record for each member of the domain, but I'm not sure how you handle the case for multple relations of the same type such as sibling, uncle, children, etc. Or...would you have one record per relationship? (Actually two, since both members of each relationship would have a record specifying that relationship)

Is this what you mean by a self-related table?: Have a single record for each person in the domain. Each record would consist of a key for each relationship you want to track. Limiting this to biological nuclear family relations, you'd end up with a record thats something like the following:

name(PK),mother,father,oldestchild,nextoldersibling,nextyoungersibling,sex,[personal info]

Now the width grows with the number of familial relations you want to track (due to death, divorce, remarriage and bastardy) - something you can decide on at design time. And the length grows as people are born. And the statistics for working with the one-to-many and many-to-many type of relationships (like children, or sibling) are characteristic of operating on linked lists.

Is this what you meant by growing downward rather than outward?