Re: Lucid statement of the MV vs RM position?

From: Jan Hidders <hidders_at_gmail.com>
Date: 4 May 2006 15:26:49 -0700
Message-ID: <1146781609.801206.148540_at_j73g2000cwa.googlegroups.com>


dawn wrote:
> Jan Hidders wrote:
> > dawn wrote:
> > >
> > > OK, so you told me the jury was out regarding modeling and implementing
> > > with non-1NF data (or something like that);
> >
> > Not exactly. What the jury is out on is whether you can still have both
> > efficiency and data-independence at the same time, which requires
> > powerful query optimization.
>
> Ah, that data independence thing again.

Yep.

> There are plenty of
> requirements and I definitely do not want changes in the need for
> additional disk or any physical changes like that to prompt a change in
> software, but I still don't grok this requirement fully.

?? That has only marginally to do with data independence.

> For example, do we want the requirement that if data are moved from
> schema-A on host-A managed by subsidiary-A to schema-B on host-B
> managed by subsidiary-B, then must not be a need to change the logical
> data model used by the applications, so that applications can run
> without changes simply by redirecting (outside of the apps) requests
> for such data to another data source? Obviously, that would be nice.

?? That is also not really a typical case of data independence.

Are you seriously telling me you do not understand the fact that if I organize the same data differently on my disks this influences my ability to efficiently answer certain queries? Have you never done any programming that concerned disk-based data structures and algorithms that went beyond the trivial? Your comments give this impression.

> I'd like to take the overall functional requirements for a database
> management system (which are not the same for every organization, I
> will grant) and optimize all together rather than declaring a single
> non-functional requirement as fixed in stone, while users might not get
> what they need. Obviously, we want to have maintainability,
> reliability, security, and all other non-functional requirements met,
> but these need to be turned into functional requirements, it seems,
> before they can be tested.

Depends a bit on your notion of 'functional requirement' but things like security can certainly judge by the presence or absence of certain features.

I think I'll stop here. Not that I don't have anything to say about your other comments, but my time is limited, my girl-friend is getting impatient, and I'd rather focus on one or two points than have ten micro-debates within a discussion.

  • Jan Hidders
Received on Fri May 05 2006 - 00:26:49 CEST

Original text of this message