Re: Lucid statement of the MV vs RM position?

Jan Hidders wrote:
> dawn wrote:
> > Jan Hidders wrote:
> > > dawn wrote:
> > > >
> > > > 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.

> I don't know any, nor do I expect something like that to exist. Such
> comparisons are difficult because of several reasons. The claims of the
> RM are mainly wrt. the functioning of an IT department as a whole
> within a certain type of context. That is hard to recreate in an
> experiment.

OK, so you told me the jury was out regarding modeling and implementing with non-1NF data (or something like that); then I told you that there are production systems out there, if the jury really wanted to know; then you said they have already gathered data; then I tried to ask "where is it?"; and you said "I don't know any, nor do I expect something like that to exist."

So, I think we talked past each other on that one. If RVAs and other non-1NF structures are now accepted in theory and implemented in practice, then when should they be used? In theory (since I don't know in practice with SQL-DBMS's), there are some good times to model in NF2, I would think. For example, when a property of a strong entity is multivalued, it makes sense to model it as a relation or list-valued attribute. For example, for most implementations, a set or list of valid e-mail addresses for a person. Of course there are veritical industries where it makes more sense to retain e-mail addresses even when there is no person associated with the e-mail address.

If we are going to (re-!)introduce nested structures, we should have a good idea when a logical data model should include them, or at least know some best practices. If a particular DBMS is not up to the task of working well with performance or ease of queries with the nested structures, then perhaps the actual implementation needs to normalize (1NF). But I'm not seeing nested structures yet in logical data models (not that I'm seeing all LDMs).

> > > > [...] 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.

>

I would be interested in the use over time, with multiple apps.

> > > Any extra required
> > > programming would of course make the comparison meaningless.
> >
> > Not to an end-user, but, yes.

>

I agree that if you have to hold everything and write new code, that would matter to end-users, but whether a system was written this way or that, end-users would typically not consider such comparisons _meaningless_, even if they also care about the underlying technology. Cheers! --dawn Received on Mon May 01 2006 - 23:57:48 CEST