Well, I don't know if I can answer your question, but here's some thoughts...
Do all children really have to have a parent? By this I mean, will there ever be a case where you might want to enter a child without knowing which parent to attach it to? Might be worth considering, that way you could enter the info in but if you weren't sure exactly which parent you could leave it blank. Then later on you could run a report on all children with no parents. That might help to organize and track research. Just something to think about.
Now, about the database design...currently:
id
firstname
lastname
...(other info)...
parent (points to id of parent nodes.)
children (array of children nodes?)
That looks good on paper but you'll find that it is not normalized when you go to implement it. Bascially normalization entails designing your DB so that each field has only 1 value and that each row of your database doesn't repeat data and doesn't have null values. This is an ideal goal, not a hard rule. (Check out http://www.phpbuilder.net/columns/barry20000731.php3 for a good article on normalization.)
The biggest obsticle to normalization in your current setup is the parent and children fields. The parent one has the most readily appearant fix (assuming a fixed number of 2 parents): split it up into a mother and a father field. Then each one will point to the appropriate parent. Please note, this will only work if everyone has only 0, 1, or 2 parents, period. If anyone has 3 parents or more, you'll have to use a different method.
Speaking of the childern, the first question that comes to mind is: Do you really need to keep track of that? The reason I ask this is that your database is already keeping track of the children because it's tracking the parents. If you track the children, you'll be introducing redundant data that you'll have to keep track of very carefully inorder to avoid problems (most especially when you are updating or making changes/corrections to existing data).
Just incase it's not clear what I mean, here's an example: all you have to do right now to find Bob's children is do a search like this:
SELECT FROM yourtable WHERE father="Bob";
This will return all everyone who's father is Bob (ie, all of Bob's children). And to find all of Bob and Betty's children:
SELECT FROM yourtable WHERE father=BOB and mother=Betty;
So, now that I think about it, it really looks like it it would be best to just track it this way. (The other way is to maintain a seperate table listing only parent-child id pairs.)
Just modify your table slightly and you'll be set:
id
firstname
lastname
...(other info)...
father (points to father id)
mother (points to mother id)
I apologize for using that much space, without even directly answering your original question, but I think that it pretty much answers itself now. You should be able to generate a tree by starting at the top and searching downward for children. Or you could start at the bottom and search upward for parents. With this type of method you would basically just generate 1 level of the tree at a time. There's prolly some other ways to do it too, but that's the easiest one I can think of. As long as the underlying database structure is solid, you should be able to generate your tree, make changes, and perform searches fairly easily.
