Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> comp.databases.theory -> Re: One Ring to Bind Them

Re: One Ring to Bind Them

From: Dawn M. Wolthuis <dwolt_at_tincat-group.comREMOVE>
Date: Tue, 29 Jun 2004 20:13:58 -0500
Message-ID: <cbt44u$8vd$>

"Marshall Spight" <> wrote in message


> "Bill H" <> wrote in message
> > "Marshall Spight" <> wrote in message
> > news:GipDc.159689$3x.28156_at_attbi_s54...
> > >
> > > Perhaps I misunderstand, but MV has only the one kind of
> > > relationship it is capable of understanding: containment.
> >
> > I'm not sure why it is so difficult to express this concept. An MV
> > environment is both a data store and an application server. It is _NOT_
> > RD model. To discuss its attributes strictly from a datastore
> > is neither fair nor accurate. To understand its methodologies for
> > solving business problems requires the willingness to work with its two
> > functions: storage and application properties/methods/rules/etc.
> I read that paragraph a bunch of times, but it didn't seem to
> address my statement that MV has only one kind of relationship
> it is capable of understanding. Does it have relationships besides
> containment that it can understand? An example of a non-containment
> relationship would be cool, if the example does not require hand-written
> application code to work.

I'm not sure whether this answers your question as it depends on what you mean by "relationship" but here is another type of relationship -- each file(function/entity) requires a unique identifier for each record (instance/row-ish) so that you have this relationship for a file named People, for example

People(12345)={all attributes of this person including those stored directly as part of the People function and those derived via links to other functions}

Another type of relationship it understands is a link placed in a "virtual field" for derived data. So, even if the street address for People(12345) is not part of the "base relation" (is not stored "in" People, the function to link a foreign key to another file is a relationship that is understood. So, once that virtual field is defined, I can ask the database to

List People Name Address

> I think the MV and the RM world divide things up very differently.
> I will note first that "storage" is not a first-tier property of RM,
> but it is a useful, second tier function that most products support
> and that most applications take advantage of. It is perfectly reasonable,
> and useful, to have an RDBMS that does not persist its relations.
> We could still call this an RDBMS, but we couldn't call it a "datastore."

Yes -- if you remove the storage feature of MV, you get something very close to XML. So, if you add it back in, you have something very close to "an XML database" which is the creature that the big database vendors are saying doesn't exist and won't be able to save your company from having to pay for an RDBMS. Hmmm.

> Another example is managing data integrity in procedural application
> code. In RM this is considered a "stupid database trick" to quote from
> another thread. There are significant disadvantages to application-managed
> integrity rules, to the point where I do not consider it an approach
> worth discussing (and yes, I've used that approach in the real world.)
> However, it may be that this approach has lower overhead in situations
> where you have small development teams and single-application databases.

I think I agree in principle that we do not want constraints in application code, but would add that we don't want them stuck in the proprietary database language, inaccessible to the application either. The odd thing is that it really "seems like" the cause and effect are different -- you GET smaller development teams when you use this approach and that is concerning to me. Something is decidedly less expensive in terms of time for maintaining and having the constraints in the same language as the rest of the application just might be one of the keys to that.

> > Secondly, solving business problems requires a great deal of
flexibility. A
> > non-relational model can, in a number of instances, provide additional
> > flexibility over and above whan the RD model can.
> Please be specific. I am very interested in specific examples of specific
> operations or structures that you feel are hard to solve with RM or SQL
> and easy to solve with MV. I do believe there are some, but I want
> to know what they are better. As it stands I have a hard time evaluating
> the claims of the MV people, even the smart/nice ones such as you
> and Dawn. I'm not saying I believe, and I'm not saying I disbelieve.
> I just want to hear more specifics.

But you see, I have a hard time evaluating the claims of people like me. I don't have proof. I am very confident that I can find aspects of the relational model that are not based on either mathematics or science (we've had many such discussions in the past half year). I do not have any scientific evidence that models other than relational have anything better going for them. I have personal experience that is insufficient as proof and a collection of anecdotes. I'm in search of better science on the matter and a mathematical model that is as useful to the practitioner as the RM.

How do you think we could get evidence? It seems to me that a class of databases that advance the "older" approaches of Cache' and PICK could beat today's SQL databases in a number of categories. How could I prove that starting with PICK would be better than starting with SQL Server if we want to provide highly scalable but relatively inexpensive and agile software development environments in the future? It seems the best I can do is prove that the relational model is not purely mathematics, but contains some amount of religious claims.

I've considered other approaches such as approaching the Mountain Dew folks to see if they would sponsor a "Dew IT" event where we put some hypotheses to the test more. I don't know what the equivalent of a placebo would be in our tests, however. Cheers --dawn Received on Tue Jun 29 2004 - 20:13:58 CDT

Original text of this message