| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
Home -> Community -> Usenet -> comp.databases.theory -> Re: Lucid statement of the MV vs RM position?
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.
![]() |
![]() |