Re: Navigation question

From: Walt <wamitty_at_verizon.net>
Date: Wed, 21 Feb 2007 15:23:28 GMT
Message-ID: <QtZCh.1032$tQ.15@trndny07>

"Andy Dingley" <dingbat_at_codesmiths.com> wrote in message news:1172053637.665300.7510_at_a75g2000cwd.googlegroups.com...
> On 20 Feb, 17:57, "Walt" <wami..._at_verizon.net> wrote:
> > "Andy Dingley" <ding..._at_codesmiths.com> wrote in message
> >
> > news:1171990396.924858.28580_at_p10g2000cwp.googlegroups.com...> On 14 Feb,
19:47, "Marshall" <marshall.spi..._at_gmail.com> wrote:
> >
> > > > select * from orders where date > '2006-01-01' and status =
> > > > 'fulfilled' and customerid = 1234
> >
> > > > You say what you want and you get just that. No sifting
> > > > through stuff you don't want; no navigating.
> >
> > > Why is that good though? Because it avoids navigation, or because it
> > > avoids round-tripping?
> > > IMHO it's avoiding the second thhat is the advantage here, not the
> > > first
> >
> > Neither of the above. It's good because it does not require the inquirer
to
> > know about anything other than the data.

>

> That depends on what you care about most. IMHO, it's _both_ that are
> important, however some may be locally more important than others.

>

> My experience comes from mid-size intranet web apps, where the real
> performance hit comes from excess round-tripping to the DB server. I
> would agree completely with Marshall's comment, "If get-customer and
> get-order run over the network, then
> this software will perform poorly." However I don't see
> _this_statement_alone_ as sufficient reason to avoid navigational
> solutions. You can navigate on the DB server alone without requiring
> round-tripping.

>

You are right. See my comments elsewhere in this discussion concening data dependency.

Arguing for the RM on performance reasons alone is a mistaken argument. In general equivalent Codasyl databases will outperform relational databases. It's when you go to use the data in unforeseen ways that the RM pulls ahead.

Many of the best arguments for RM apply only to "nexus databases" rather than to "embedded databases".

By "embedded databases" I mean databases that are only used by components of a single application.

By "nexus databases" I mean shared data banks that are specifically intended for the sharing of data among (otherwise) separate and disjoint applications.

As the percentage of new databases trends towards the "embedded" type, the concept of what a database is for is gradually morphing into something else. Don't ask me to explain. It's beyond me. Received on Wed Feb 21 2007 - 09:23:28 CST