On Dec 9, 2009, at 9:41 AM, bruno desthuilliers wrote: > On 9 déc, 14:10, Eric Chamberlain <[email protected]> wrote: >> Hello, >> >> We're not sure how can we represent the following data structure in the >> django model? >> >> Grandparent Object >> First Name - NULL >> Last Name - NULL >> City - Anytown >> Ancestor Object - NULL >> >> Parent Object >> First Name - Bob >> Last Name - Smith >> City - NULL >> Ancestor Object - Grandparent >> >> Child Object >> First Name - Jill >> Last Name - NULL >> City - NULL >> Ancestor Object - Parent > > > Took me some times to understand this was about model instances, not > classes :-/ > > > First point, you have a tree structure. There are a couple ways to > handle trees in a relational model, each has pros and cons. The most > obvious one is the recursive relationship (also known as 'adjacency > list'): > > create table Person( > id integer primary key auto increment, > first_name varchar(50) NULL, > last_name varchar(50) NULL, > city varchar(50) NULL, > ancestor_id integer NULL > ) > > where ancestor_id refers to the Person.id of the 'ancestor'. > > The problem with this solution is that SQL has no way to let you > retrieve a whole 'branch' in one single query. > > Other solutions I wont explain here are the "Materialized Path" and > the "Modified Preorder Tree Traversal" (mptt). You'll find more on > this topic here: > > http://articles.sitepoint.com/print/hierarchical-data-database > > These solutions are somewhat more complex, but allow to fetch a whole > branch in a single query. OTHO, they usually imply way more work when > modifying the tree, so there's no "absolutely better" solution - which > one will yield the best results depends on your application's needs > and tree depth. > > >> We'd like to be able to use the child object with the NULL fields coming >> from the ancestor objects. > > I assume that what you mean is you want to lookup values on the > related 'parent' object for fields that have a NULL value in the > 'child' object. The usual way to handle this in Python is to use > computed attributes. > > >> We need to update the parent field and have all the child objects return >> the new value. The parent object behaves like a template, some users have >> write access to the child, but not the parent object or some users may not >> have write access to all the child fields. > > Hmmm... sorry but this part isn't quite clear to me. Care to provide a > bit more (or clearer) explanations ? (sorry for being that dumb). > >> We'd like to keep database calls to a minimum and avoid looping lookups if >> possible. > > Then you want a materialized path or MPTT. > >> Is there a better way to implement this? > > > "better" than what ??? You didn't say anything about your > implementation ? >
Thanks for all the great info. Looks like if we go this route we would need MPTT. By a better way, I mean, should we store our data as a tree. We can limited the design to only two levels, a parent (default values come from here if not overridden by the child) and a child (overrides some of the values in the parent). -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
