Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm working on a project and I've found that I've modeled the two largest components as trees.

My main uses so far are:

  1. Generically model physical containers (and sub containers, sub sub containers etc)
  2. Model liquid samples (and sub samples, and sample derivatives - and subs of those, etc)

I now need to model some events based on the shipment of samples e.g. collected at location X, when arrive at processing centre do Y

It now seems natural to model the events as a tree to denote which events follow on from others.

I'm starting to wonder if I am just seeing trees everywhere because I want to, or if its a legit approach?

Edit To Answer Some Points Raised

Everyone seems to agree with trees for the containers.

For the liquid samples, although there are various types - what I really need to track is parentage so that given any sample, I can quickly find all things that derived from it in some way. I have been told I can assume that samples will not be combined so all sub samples (or derivatives) will have only 1 parent.

As to the events, yeah I think I was just going for a tree for ease. It doesn't make much sense to me after reading comments and further thought.

Thanks all for the input.

share|improve this question
2  
If it works for you, and does not hamper the production of code it probably should be fine. And you probably can get higher performance when retrieving data from trees. –  AttackingHobo Jul 6 '11 at 16:39
1  
@Job maybe it's an arboretum? –  DavRob60 Jul 6 '11 at 19:09
add comment

5 Answers

up vote 5 down vote accepted

It's a legit approach when you have data that can be nested very deeply/recursively, such as physical containers or for hierarchical data (such as a corporate organization tree, or a filesystem). Your second example may or may not fit tree-models as nicely but I'm not sure since I don't know how different a sub sample is from a sample derivative.

Shipments of samples from locations, there only seems to be three levels to this tree: The sample, the location it's from, and the processing center. It may or may not make sense to arrange the hierarchy in this fashion (you'd know better). If you're worried about tree-overuse, you could use nested hashmaps or something like that. Even if you don't use trees internally, they are still good for UI displays of this sort of data.

share|improve this answer
    
Yes I am dubious of 2 - it would seem like there could be multiple types of relationships between different liquids - not a strict hierarchy. The event scenario I do not really understand but I don't see it as a hierarchy at all. It could be a list of events and rules that apply to an object and that could be a parent child relationship but may not always be. Without a really deep understanding of the business domain modelling questions like this are impossible to answer but there is enough information here to think that Yes, the OP needs to reconsider these two cases. –  Jeremy Jul 6 '11 at 16:33
add comment

You have to do what works for you.

If you think that you can better understand a project and demonstrate it to other people using your methods, there probably the right ones.

share|improve this answer
add comment

Generically model physical containers (and sub containers, sub sub containers etc)

This most certainly seems to fit the Composite Pattern and I see no issues with a tree-style design. Nothing to really add that others haven't already pointed out:

  • easily iterated/traversed
  • observable hierarchy

Model liquid samples (and sub samples, and sample derivatives - and subs of those, etc)

This doesn't seem to fit a tree-style or composite architecture, IMO. This almost sounds like a good fit for the Prototype Pattern, that is, if I correctly understand #2.

share|improve this answer
add comment

@Frustrated's answer is good. I would only add: think about what you're doing with the information. You should use the structure that has the most simplifying effect on the code you have to write.

Trees are a good useful conceptual structure, but they don't have to be implemented as a typical memory tree structure. Issues of memory or time efficiency only matter if the tree is large or accessed at high frequency. An example of another representation is as a simple linear array/list of records or structures, where each record is marked with its "depth", as in a bill-of-materials or chart-of-accounts.

One question I would ask is - do you have uncle/cousin-type relationships that reach across the hierarchy, like variable names in a program, or relative links in a file structure? If so, you need to think about how to represent those.

share|improve this answer
    
I'm not actually using a tree in memory but as a storage mechanism in the DB using a proprietry ms sql type. In the first 2 scenarios, I do not have uncle/cousin type relationships - and I think I would probably ditch the tree mechanism if I did. –  Jonno Jul 7 '11 at 9:11
    
@Jonno: I would be nervous of using the proprietary ms sql type. I have had so much pain over the years caused by ms or another vendor simply deciding they no longer wish to support something our company happened to write a lot of code against and had hundreds of copies in the field. Example: DAO. Example: Intel Fortran 9. Example: SPlus 6.1. –  Mike Dunlavey Jul 7 '11 at 17:29
    
We have a strange contractual requirment to not change architecture of a project once it goes live. I understand what you are saying but we have the plus/curse of never upgrading the database once it goes live (we still have sql 2000 clusters for example). So loosing support, we are just kind of used to - good advice though. –  Jonno Jul 8 '11 at 9:32
add comment

Trees are okay if you can guarantee that there should only be one path to an item, i.e., that users will only think of things as being "in" one place. A set of nested containers, sure.

But a hierarchy of liquids--that seems like not as good of a fit. I could imagine wanting to get to a particular derivative starting at different places. In this case I might use a directed acyclic graph instead of a pure tree.

share|improve this answer
    
you may well be right. The end users see the samples as largely seperate - without parentage. There is however a requirment to track all sub/dervived samples from a given sample. I am really looking to the tree to provide this use case. –  Jonno Jul 7 '11 at 9:14
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.