I have a need to store a structure where N parents will have 1 to N children and each child will have 1 to N children. I would like to store this in a db in a manner that is both relatively performant and highly extensible w/o requiring db schema changes.
Each parent must be unique and N parents might have the same child. However, that child may have different children depending on the parent. (clear as mud?)
It may be easier to describe this as parentA may have a male child that has certain attributes (brown hair, brown eyes). parentb also has a male child but this child has blonde hair and blue eyes. I need to store each of these children (male and female) and each attribute (hair and eye color) in a normalized fashion and relate them in such a way that when I query parenta I get al of their children and those childrens attributes.
I have done a bit with tree structures and hierachical structures in SQL but am having a hard time conceptualizing this particular scenario in a manner that meets my requirements of performance and extensibility. Children and associated attributes will be added at regular (if not frequent) intervals.
Thanks in advance. I know clarification will be required.
Additional clarification
Ok, it appears a different example may be needed. Let’s use the good-old example of a car.
CarA and CarB both have steering wheels, engines, and tires. CarA’s steering wheel has radio controls on it. CarB’s steering wheel does not. CarA has a six cylinder motor and CarB has an eight cylander motor. I need to model the relationship between each car and each feature with that feature’s attribute. Am I helping at all?
-rb
if this is fixed at three layers and they are conceptually distinct (as in your extended example) then i think you are being confused by the idea of trees where they are not necessary. just use tables and relations as you would with any other problem.
trees are necessary where the nodes at different levels are “the same thing”. but they’re not a great fit with sql, so i wouldn’t try to use them where they don’t seem to be necessary.
update. from your comments below i think that you are saying that children are divided into classes or types, and that the possible attributes depends on the type of the child, but that the values of those attributes depends on the parent.
in that case you have a completely different problem, more like OO inheritance. the simplest solution that i see is that you can have a different table for each kind of child. then each table has different columns for the different attributes. child tables refer to parent tables.
so you would have a parent table with IDs. then you might have a child table for “admin sites”. each row of that child table would reference a parent via the ID and contain URL, CSS, etc as columns. another child type, like “database config page” would be in another table, with a different set of attributes.
if you have attributes in common then you can either repeat them in each table or have a “superclass” table.
solutions like this can get quite complicated and i’d suggest asking another question once you have a clearer explanation of what you want. there’s a good explanation of the options here – http://www.sqlalchemy.org/docs/orm/inheritance.html (ignore the parts relevant to SQLAlchemy and just look at how they are using tables in different ways to model inheritance).