Re: Navigation question

On Feb 21, 9:23 am, "Walt" <wami..._at_verizon.net> wrote:
> "Andy Dingley" <ding..._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.

Yes, that is what I have seen as well and a reason I have expressed optimism of late (not being altogether comfortable to limiting my database tools to those in line with the RM).

I work with what are now called "embedded databases" but don't be fooled by that tagline as they are used extensively for enterprise systems and multiple applications. It is the case that there must be some coordination among those using the DBMS, however, as the DBMS itself does not provide everything required to make all users independent of each other. Just as an RM-related DBMS typically has a central group to administer it, there is often some centralized body building on top of, rather than within, the DBMS in a shop using an embedded DBMS with a data model that is not strictly relational.

I are correct that there is no good argument from a performance basis for the RM. I have also seen that it is easier to migrate requirements over time with non-RM related DBMS's, so although there are some good arguments for why that might be easier with a strictly SQL-DBMS, for example, in practice I have not seen that to be the case. That leaves your other reason, the need for a "nexus databases". I suspect that more folks think they need such than really do, but I do agree that if it is required, then the RM is a good place to look.

Thanks, Walt. --dawn Received on Wed Feb 21 2007 - 18:06:00 CET