On Oct 16, 8:03 pm, Nathan Hammond <[EMAIL PROTECTED]> wrote: > I can't imagine that the speed of the suggested queries (with self- > joining and nesting), even optimized, would even come close to the > speed of the queries I'm proposing.
Yes, clearly the queries you suggested are going to be much faster. > Note that my original goal was two-fold (speed and simplicity) but as > an added bonus it provides a myriad of other benefits. I feel that the > results would be more robust in terms of protection against corruption > as opposed to less so (the most dangerous operation, move_node, > involves only a single row change in the adjacency model). Maybe I'm missing something, but I don't see how that would work. Because MPTT takes care of both nesting and ordering within each generation (is that stretching the family metaphor too far?) surely it requires just as many row changes. The adjacency list model per se doesn't do ordering so you need another field where all rows need changing, just like MPTT. > It makes it > easy for the code to be maintained by others because with one glance > they can see exactly what is occurring. It makes it easy to ensure > that different database platforms with slightly different takes on > ANSI don't need different queries (I admit, I don't know if that would > be a problem, but I could see it being one--we are using PDO to enable > multiple DB backends). I am fairly new around here, but I have taken the time to look fairly deeply into how Habari works, so I know about the use of PDO - it's good chunk of what makes Habari awesome. > Yes, there is a SQL-based MPTT approach to those three queries but I > find that it fails to provide any of the benefits that the adjacency > model does in these three scenarios (speed, simplicity, > maintainability, robustness, portability). In summary, I see a hybrid > approach as the optimal solution as it gives us the benefits of each > whenever the output scenario makes better use of that approach. Contrary to you - at this point at least - I see the hybrid approach introducing more complexity without benefits to outweigh it. Of your five benefits (speed, simplicity, maintainability, robustness and portability) I'm only convinced on speed. Yes, a hybrid model would provide more simplicity, but only in the three queries you mention. It only provides more complexity in the update queries. Maintainability would, I believe, be made worse not better. I understand your argument (which I assume is in support of robustness) that should some corruption occur, the tree could be (partially at least) re-built from the mptt_parent field - but I don't see that as a reason to include it given the greater levels of complexity introduced. I'm not sure how portability is improved. If the idea is that the lists might be more easily exported (for import into some other system - or for whatever reason), that's true only so far as developers (of either the export function or the import function) don't take the time to understand MPTT - which, given it's now an important part of Habari, is probably a requirement. Sorry if I sound confrontational, I don't mean to be. Like you I'm just here to try and play my part in steering Habari development in the direction I think constitutes best of breed (and sorry about using that awful term). Since stumbling across Habari a year or so ago I've spent many hours dissecting it and following the development. Doing that has taught me many lessons, so I'm very grateful for that. I'm only just now starting to find my voice in the community (an hopefully some time for something more substantial than imparting my thoughts). I'm not going to feel put out should the community decide to choose your suggested path, but I genuinely think (but can still be convinced otherwise) that mptt_parent introduces more complexity than its overall benefit justifies. Cheers, Simon --~--~---------~--~----~------------~-------~--~----~ 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/habari-dev -~----------~----~----~----~------~----~------~--~---
