Navigational Vs Relational
Navigational Vs RelationalOne of the long enduring FlameWars is that between NavigationalDatabases (more generally, NavigationalDataStructure?s) vs RelationalDatabases (more generally, the RelationalModel). Relational has proven its superiority over navigational in certain problem domains--such as the storage and processing of enterprise data--and some argue that it is superior to navigational in other domains as well. Others argue that there is a place for both. (I'm not aware of anyone arguing that navigational is superior to relational in all places)
[moved from NavagationalVsRelational?]
Re: "both approaches have distinct advantages and disadvantages"
That people agree on? Such as?
Relational provides fast ad hoc queries. Navigational provides fast everything else.
I did not realize you were talking about machine performance. I was thinking more of a software engineering perspective. Anyhow, do you have any evidence that nav is faster?
Yes.
The borderline between ad hoc and non ad hoc is kinda fuzzy I would note.
Not in my experience. The difference is clear. One is hard coded into the software. The other is configured at run time.
I will agree that if you perform a fixed set operations on the "nodes", then a custom-built nav engine for just those transactions would probably be faster. Then again, relational does not dictate implementation. If the engine can find a fast algorithm and/or index to perform a given task or pattern of tasks, then it could perhaps compete with custom-built stuff.
It can approach a navigational database, but never surpass it.
That is the field of automating query optimizations, which is something I am not an expert in.
Ok, then another approach: don't confuse any old navigational database with CODASYL. Some solution domains have a very strong hierarchical structure as an instrinsic part of them. Also, they have no need of ad-hoc queries. This is why LDAP servers exist, for one thing. Often, the kind of stuff that LDAP servers are used for would be 1) a pain to do with any current RDBMS, 2) totally non-portable if done with any current RDBMS, 3) a waste of the resources needed to run most current RDBMS's, if done that way.
I could have sworn there was a huge LDAP-related debate somewhere around here. Anyhow, what things are "intrinsically hierarchical"?
Postal addresses, IP domain names, geneologies, the most widely used library classification schemes, legal documents, algebraic expressions, the org chart of almost every corporation, the executive branches ("branches", what a give-away) of every national government, every military organisation, the Roman Catholic Church, etc. etc.
I am moving this to RealWorldHierarchies.
Although I don't agree with it for software usage, one could argue that NavigationalDatabases are more "organic" like the human brain and can be better grown organically in XP-like processes. You can slap a node or link on any class/record you want to provide more info as needed. It can be compared to the "shanty-town" approach to housing. Need a new room? just tack it on top of the existing ones. Need plumbing? Just tack on pipes.
Another variation of this is that it is allegedly easier to learn navigational structures because you can incrementally add on to a project as you scale up. Relational allegedly requires more setup and modeling before it can be tapped into. It is also said that relational takes more training to understand because of its mathematical origin. However, part of the problem is SqlFlaws IMO, and not flaws in the concepts themselves. Also, DrCodd's primitives don't have to be the (only) relational operations that users are exposed to. We could introduce easier-to-understand relational operators IMO. DrCodd was smart, but a poor marketer and packager.
I think the historic record shows that while a NavigationalDatabase offers...
RelationalDatabases are generally much less efficient, in terms of time and storage space. But they're much more flexible: Much maintenance, such as adding and changing indexes, are largely invisible to the users (both human and program). And the generic un-specific organization of data in a RelationalDatabase and SQL, the DSL, both contribute to supporting new and unexpected usage of the data. -- JeffGrigg
I'm not sure about either claims for the NavigationalDatabase. I've only worked on one product that actually had both a relational and a navigational version. Performance varied wildly depending on exactly what task was being performed. Sometimes the relational version was much faster, sometimes it was much slower. As far as programming goes, the relational version was slightly less complicated, but hardly a big win either way. -- AnonymousDonor
What I've seen and heard is that well designed non-relational databases can give one to two orders of magnitude better performance -- for the work they've been designed and optimized to do. However, these results might only apply to a narrow range of applications, like some spacially related data in CAD systems, for example. Experience seems to have shown that when your needs deviate from the narrow range that the non-relational database was carefully designed to serve, things get really bad quickly -- typically much worse than an equivilent RelationalDatabase. And it can be really really hard to change the design of a NavigationalDatabase, as you are likely to have to redesign most if not all of the programs that use it. -- JeffGrigg
EditText of this page
(last edited November 8, 2009)
or FindPage with title or text search