Hacker News new | past | comments | ask | show | jobs | submit login

There's a major niche in which hierarchial DBs are quite common - filesystems. While there have been attempts to graft relational features onto them ("journaling" overlaps strongly with transactions, symlinks, etc.), apparently most people haven't historically considered the ability to do arbitrary joins over a whole filesystem to be worth the impact it would probably have on performance.

Also: Hierarchial databases are very different from key/value stores. K/Vs are flat (joining, batch consistency checks, etc. are usually done clientside in a faster/safer language than the DB was implemented in, such as PHP), while hierarchial databases are (naturally) hierarchial. If a client searches for data in a directory, it will only see the nodes in that directory, or those found by walking any subdirectories. While this can be very fast (most records won't be in the same directory, so the first operation has already reduced the search space considerably), much data fits poorly in trees, and constantly rearranging subdirectories or adding symlinks is at best a workaround for the massive conceptual mismatch.

OTOH, it's a good fit for some cases - we're communicating on a hierarchial database right now. As moving one comment thread from one post or parent comment to another would be incredibly rare (if it were possible), a lot of DB functionality to allow flexibility in data modeling can be discarded. Modeling the discussion as a tree of nodes (S-exps, in this case) with pointers to parent comments, subthreads, user IDs, etc. is pretty straightforward.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: