Re: Lucid statement of the MV vs RM position?

Jan Hidders wrote:
> dawn wrote:
> > Jan Hidders wrote:
> > > dawn wrote:
> > > >
> > > > My goals would still include getting the word out about this fatality.
> > > > I doubt many undergraduate courses teach that 1NF, as we knew it, is
> > > > dead, for example. I sure don't see that knowledge having made it into
> > > > the practitioners "common knowledge" as yet.
> > >
> > > It shouldn't.
> >
> > Yes, it should. Should all XML documents be in 1NF? If not, why not?
>
> That is neither here nor there. The question is not if you should
> always model your data such that it is in 1NF.
>
> > > Finally, whether using
> > > nested relations / lists is in practice a good idea depends on how
> > > efficiently your DBMS supports them
> >
> > Agreed.
> >
> > > and for example can do decent query
> > > optimization on them. AFAIK the jury is still out on that one,
> >
> > Well, there's more than 30 years of production apps out there running
> > flavors of MUMPS, PICK, and others from which the jury could gather
> > data.
>
> They already have done so, and they already know why they work
> efficiently under certain circumstances, and under which circumstances
> they have problems.

I've tried to find those "they" people to see what they have found out.  Can you point to one study out there that compares Pick with SQL-based products? What is out there that compares any non-SQL (or SQL as a second language) databases with SQL DBMS's without using SQL against the non-SQL database? I'm apparently doing a lousy job of searching. I'm not looking for theory on this one, but actual studies of real software solutions. It does seem like there would be such, but I'm not finding 'em.

> > Even if you don't like the lack of DBMS-defined constraints on
> > the way in, those are not required for determining read-only query
> > performance. Unfortunately, there are no industry performance measures
> > of which I am aware that are not designed strictly for SQL-DBMS's (or
> > do you know of some?)
>
> Simply translate they SQL queries to queries in the ad-hoc query
> language of your favorite system. Presuming, of course, that this
> ad-hoc query language is powerful enough.

You would need to implement solutions to the same business problems. It is highly unlikely you would model the data identically for the two systems. Then if you ask the same question of each and a compiled language is executed via a virtual field for one and SQL is used for the other, is that how you want to compare? I would suggest the SQL folks would not want to compare on performance, although with some of the latest approaches to performance improvements with SQL tools, they might now be at the point where they would be willing to do so if there were financial incentive to do so.

> Any extra required
> programming would of course make the comparison meaningless.

Not to an end-user, but, yes. --dawn Received on Sun Apr 30 2006 - 22:04:14 CEST