Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
User Journal

Journal blinder's Journal: [Programming] Child/Sibling: Possible Approach 12

well, as i said in this journal entry i think i do have a solution. and here it is, its called the nested set model.

there's a decent description of it here

the reason i am still a little hesitant is that the concept still isn't 100% clear for me. the concept of "left" and "right" is a bit fuzzy. i'm going to actually play around with it... but the nice thing is, in the above article, all of our use cases are represented. so, i'm a work with it and see if its a fit.

This discussion was created by blinder (153117) for no Foes, but now has been archived. No new comments can be posted.

[Programming] Child/Sibling: Possible Approach

Comments Filter:
  • 1) If you aren't 100% clear on the concept, steer clear. Play around with a few samples first and you should be able to get a better understanding, but if it doesn't click, it could lead you into dangerous, unfamiliar territory. (Not that I'm telling you something you didn't already know.)

    b) The nested set model looks kind of interesting, but I wonder how resource intensive it will be when adding/deleting nodes? It looks as though every node to the right of the one being modified will need to be updated. H
    • by arb ( 452787 )
      I thought that looked familiar. Nested Sets is something Joe Celko has written a lot about. He is both a genius and a madman - be sure you really understand this stuff if you do choose to implement it. I looked at this approach a few years back and decided it wasn't for me, but YMMV.
      • Likewise, I built a sorter a few years back that sorted a simple child/parent table into a tree hierarchy. I looked at the Nested Set model and decided it was "clever". I don't like clever.

        Maybe I'm missing the finer nuances of the problem and the solution though.
        • by blinder ( 153117 ) *
          heh, i wish i was allowed to say more about this project, but with the constraints i have, especially with timetable and about a dozen other factors, we not only have to be very clever, but if we are going to pull this off, we have to innovate as well.

          in this project, the old ways of doing things and the establishment need to take the back seat. we are being asked to perform a miracle, and if we can pull it off, it will be because we were clever.
          • Like I said, I think I'm missing most of the problem, so I don't see the benefit of the solution.

            How many elements will realistically be on a page? 50? 100? 500? 1000?
    • by rk ( 6314 ) *

      It looks clever, and IMHO, that's the problem. Always remember Kernighan's comment on the relative difficulty of debugging and programming. arb is right, too. If this table has many rows and gets updated frequently, it's going to perform like a dog. I believe it could be refined to make the left and right values more local, so a change of elements doesn't touch unrelated rows.

      I'll admit that I'm a bit undercaffeinated at the moment, but what's wrong with just a parent id and sequence column? That giv

  • that's interesting. when i did a time and attendance system for my last employer i just did it the first way they show. it wasn't difficult and performed well, but the employee table had less than a thousand rows. so i don't know how all my apps would have scaled, but it worked well for what it was. the one thing i definitely didn't do was to have the top person (everyone had an employee id and a manager id) with a null manager. i hate nulls. i made the last person have their own employee id as their
  • Can also be implemented with a binary tree. That should make the left-and-right more clear in your mind, if you've had pointers. If you haven't had pointers, consider coding this in a List language rather than a P-code language, as list languages take care of the pointers for you.
  • Comment removed based on user account deletion
    • by arb ( 452787 )
      Also, if whoever comes in to maintain doesn't "get" it, that could be a nightmare for them as well.

      Give this boy a cookie! Maintenance is definitely going to be an issue with any radical approach - and that is something I know only too much about with the project I work on. You have to remember to factor in how much time it will take a new member of the team to get up to speed and what is the likelihood they will misconstrue something and botch the job? For example, it can take even the best candidates a go
  • Perhaps not. I can't say that I understand programming SQL because I don't. However, one of the thigns I have been doing for several years now is litigation, specifically, utilizing databases (especially Concordance [dataflight.com]) to keep track of the documents. One of the goals we have is to capture the manner in which documents come to us. Industry standard uses the hierarchy of Source->Box->Folder->Document->Page. So you would have pages which are stapled together to form a document which is contained

Anyone can make an omelet with eggs. The trick is to make one with none.

Working...