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

You got it. YOu should only have to trace nuclear family realtionships, because all others can be derived from these. ie, an uncle is a father's brother. So to handle all cases, you would only really have to have 5 relationships: Mother, Father, Child, Sibling, Spouse.

>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.

Gets more compicated if you want to track marriage history- you would have to implement a marriage record table. Fields could include a link to the wife, a link to the husband, a date range of the marriage, and even a link to the whore that broke up the marriage :-).

>And the length grows as people are born.

Yup.

>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.

Sort of. More like a linked net. A list only has one relationship on each side, where this structure could have 5 (or more).

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

Exactly.

I have never implemented a table structure like this, I just remember a case study in college that dealt with this. I am not even sure if a relational database is the type of database needed for this, but it seems so.