Talk:Navigational database

untitled

I think this topic should be in lower-case, but I don't know how to change it without starting over.

thoughts

A few criticisms and thoughts.

Firstly, the title. I don't think it's the database that's navigational, I think it's the DML (database manipulation language). The same database can have more than one style of interface.

Secondly, the suggestion that SQL doesn't scale down seems both wrong and irrelevant.

The term is indeed due to Bachman, and it would be useful to quote some of the things he said. IIRC correctly it was a powerfully-argued paper and some retrospective analysis would be quite interesting.

Bringing the idea into the present with the reference to DOM is good, but the relevance needs to be stated.

Mhkay 22:04, 16 September 2005 (UTC)

A request for those DB experts out there: give us an example, in a pseudo code perhaps, of the difference between a navigational language, and a relational one.

Posit a database containing retail transactions, so the information one would expect to have is the items that could be purchased and their prices, and the items actually purhased, and the quantity purchased.

Thanks

Hacksaw 21:03:05, 2005Oct30 (UTC)

The article seems to be describing the scaling issue rather poorly. All relational databases have problems scaling up, not down. This is due to the search-based nature of their operation. Anytime you want to find something, even with a primary-key, the database engine has to search for it. This is because relational queries are based on the contents of a record, and the database has no foreknowledge of where any given content is. A navigational database, on the other hand, accesses things by unique address. Each record has such an address, and the database engine knows exactly where each address can be found. It only has to go to it -- no searching.

A simple analogy may help to explain this difference. Suppose you're looking for a particular person in a large city. You could:

1. Try every house in the city (sequential scan); or
2. Consult a telephone directory to locate their address (index scan); or
3. You could go directly to their house, assuming you already know the address (navigational approach).

The last method is going to be the fastest as it doesn't involve any searching. Obviously, there's still the overhead involved in actually getting to the address, but all methods incur that same overhead eventually. The key point is that it doesn't matter how large or small the city is -- you can still locate the point of interest in constant time.

The first two methods are used by relational databases since they have no foreknowledge of where any given content is. As fast and efficient as modern RDBMSs may seem, they tend to become really sluggish as databases get very large and load increases. This is a direct result of the fact they have to run a search to find anything. Navigational databases don't have this problem, since they access things by their direct address (i.e. they know in advance where things are).

Mathematically speaking, relational systems exhibit a complexity of O(n) for sequential scans and O(log n) for indexes. Their search performance drops off as things get bigger. Navigational databases have a complexity of O(1). Their performance remains fairly constant as sizes increase.

Siggimoo 21:13, 3 October 2006 (UTC)

Deconstruction

Would I be incorrect in thinking that a Wiki, and, indeed, the entire WWW is a navigational database? It has dynamic content, and you can get from point A to point F by following links and navigating through points B, C, D and E.

Answer

This is actually a very good analogy. The relational approach is using Google to find pages. This is what differentiates the two models. Relational is about matching content to find relationships (e.g. find all orders whose customer ID equals x). Navigational is about jumping directly to specific records (e.g. get these specific orders).

Which nicely highlights the elephant in the room regarding relational approaches to data management: You can only find what you know how to look for. (Querying for “everything, but …”, as in blacklisting, is not a viable way in practice, unless the universe is really tiny.) Outside of that is just a huge vague “here be dragons”. There’s no requirement of completeness. — 89.0.126.54 (talk) 01:07, 17 November 2014 (UTC)

Partnership Model?

Can someone provide an explanation of "the newer Partnership Model" discussed in the Wikipedia text? There appears to be no Wikipedia page for this text, and Google searches only turn up information related to Riane Eisler. JohnZabroski —Preceding comment was added at 19:38, 16 January 2008 (UTC)

Transactional database

Transactional database points here, but it is not explained in the article. I am not sure this is correct, though. -- Beland (talk) 02:14, 5 March 2013 (UTC)

That’s definitely not correct. The two concepts are completely orthogonal. None requires the other. — 89.0.126.54 (talk) 01:10, 17 November 2014 (UTC)

Unfounded nonsense and weasel words in the “criticism” paragraphs.

Which “critics”? Who are those “some”?

I know the scientific community around this quite well, and the whole part is just plain made-up. No sane person who knows anything about the subject would make such comparisons, given that graphs, on which this concept is based, are the mother of all data structures, and set-theoretical approaches have quite their own share of problems.

Both approaches are not good or bad… they just are.

One would only have to imagine a desktop OS file system based on set-theoretical approaches, to realize how bad of an idea that would be.

Besides: We are long past the blind demonizing of GOTO and its pro-idiocracy mindset of forcing the lowesd common denominator upon everyone, just because some are too damn retarded to be able to handle and use GOTO properly. Those folks can join their equals at the WhatWG, for what it’s worth.

— 89.0.126.54 (talk) 00:57, 17 November 2014 (UTC)

Bug in the example pseudocode

I think there's a bug here:

get department with name='Sales'
get first employee in set department-employees
until end-of-set do {
  get next employee in set department-employees
  process employee
}

The "process employee" step needs to come before the "get next", otherwise the first employee is not handled.