Thanks or these replies Robert and Mark! I guess that keeping the ancestors as a string in the database makes more sense than I first thought. It is interesting that Robert refers to this as 'caching' the family-tree, which obviously it is, but I've not really thought of caching information like this (ie database level relationships) before. Consequently, as Mark says it needs to be updated whenever a name changes, which shouldn't be too difficult to do (cycle through all the descendants and update that row?).
This has the added advantage of acting as a sort of permalink row as well. Thinking about pretty urls, it wouldn't be too hard to use this string to generate: http://appname/people/abe/homer/bart This would be the url that took you directly to Bart's url. Could I use the '/' character as a separator at the DB level? Robert - I really the idea of hashing the string to limit the length, I've never thought of this as a use for hashing before, thanks! Mark - I'm not sure what you mean by this: > you should put the name match into the > SQL conditions rather than in a Ruby loop. I guess that you mean to use SQL rather than looping through ruby arrays, but I'm afraid my SQL is very poor - I usually only use the Rails helpers to do basic stuff. I'm struggling to follow your example, but I guess that it corresponds to what Philip was alluding to by saying to construct a joins string? ......And if I used this SQL method, which would be the most efficient? I'm erring towards the 'cached' string method at the moment as it easily allows uniqueness validations and as I mentioned could be used to form pretty urls. Thanks so much again to both of you - I'm really learning lots more than I anticipated from this thread. cheers, DAZ On Dec 30, 12:33 am, Mark Reginald James <m...@bigpond.net.au> wrote: > DAZ wrote: > > On Dec 28, 8:07 pm, Mark Reginald James <m...@bigpond.net.au> wrote: > > >> One alternative is to make the ancestor array a string key > >> to each record ("abe|homer|bart"), allowing instant retrieval. > > > This seems like a relatively good idea, could have a string-key called > > family_tree or something and just do find_by_family_tree("abe|homer| > > bart") > > This doesn't quite feel right - it seems like the only info you should > > need to keep is a person's parent (from which you can then find their > > parent and so forth). It might also lead to some very long strings > > eventually! > > It does require maintenance: whenever a name changes you have to > update the string in all children and all ancestors. > > > > >> Another would be to build the sql iteratively: > > > This is what I'm doing at the moment - I'm using the "betternestedset" > > plugin, so have access to a "children" method that returns an arrary > > of children. Will this have all been pre-fetched efficiently? And if > > so, is the iterative code the way to do it? > > > tree = ["abe","homer","bart"] > > person = Person.find_by_name(tree[0]) > > if tree.size > 1 > > 1.upto(tree.size - 1) do |i| > > person = person.children.find { |child| child.name == tree > > [i] } > > end > > end > > @person = person > > First-generation children are efficiently retrieved in both > better_nested_set and acts_as_tree via the parent key. > better_nested_set also allows you to efficiently retrieve all > generations of children using the all_children method. > > So your current method will be making one DB call per > generation. And you should put the name match into the > SQL conditions rather than in a Ruby loop. > > But have a look at the code in my last post. It can find > the correct Bart using only one DB call by matching > up the unique ancestors chain. > > -- > Rails Wheels - Find Plugins, List & Sell Plugins -http://railswheels.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk@googlegroups.com To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
