Re: One Ring to Bind Them

"Dawn M. Wolthuis" <dwolt_at_tincat-group.comREMOVE> wrote in message news:cbt44u$8vd$1_at_news.netins.net...
> "Marshall Spight" <mspight_at_dnai.com> wrote in message
> news:nnIDc.125667$Sw.113988_at_attbi_s51...
>
> 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}

Gotcha.

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

Let me see if I understand this. You have a "file" of People and it might have, directly in it, a field that is a list of addresses, so we have one:many for People:Addresses.

In another scenario, you might have a file People, and it would have directly in it a virtual field, whose value is a key into another file. The fact that it's virtual is a metadata bit, and the file being referenced is also metadata. Again, one:many for People:Addresses.

The difference between a virtual field and a non-virtual field is one of implementation; the interface is the same either way. (Yes? No?)

> So, once that virtual field is defined, I can ask the database to
>
> List People Name Address

Uh, "List" is a command, "People" is the file, and are Name and Address fields of the file people? (Whether virtual or not?)

These files are functions because you are required to have a primary key, so the file is a function from <primary key domain> to <field range>. Are you limited having a single field that is marked unique?

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

Yes, we've discussed this before, and I believe we agree that it's important that constaints be available to applications.

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

I didn't quite follow this.

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

I'd buy that in a second. But I still want my constraints enforced (at least) centrally.

> > 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'm not asking for proof. I know you care a lot about proof, but I don't so much. Right now I'm more interested in hearing a lot of people's stories. So if you have use-cases for situations where you feel MV is better than the relational approach, I'm happy to hear them.

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

Bring on the 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?

Give me ten million dollars and 5 years and it should be no problem. Since I have neither, I'm willing to forego the whole proof thing.

> 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?

I have serious doubts about the scalability claim, but then I have an extreme view of scalability which has been skewed by my workplace. However I can believe the agile part.

> It seems the best I can do is prove
> that the relational model is not purely mathematics, but contains some
> amount of religious claims.

If I just stipulate that, will it help?

Any time we are building a model, what we are doing is making design choices. It is good if these choices are consistent with good mathematics, but even if we completely succeed at that, it doesn't mean we are doing math and not design. It's always design.

And there's not just one math, either. You come up with a formalism, and if it useful, then we rejoice. It's certainly possible for a formalism to be completely sound and self-consistent and utterly useless.

Marshall Received on Wed Jun 30 2004 - 17:01:51 CEST