Re: One Ring to Bind Them

"Anthony W. Youngman" <wol_at_thewolery.demon.co.uk> wrote in message news:KHRs8yBJtx7AFwTe_at_thewolery.demon.co.uk...
> In message <zBAEc.3447$IQ4.1222_at_attbi_s02>, Marshall Spight
> <mspight_at_dnai.com> writes
> >
> >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?)
>
> Not quite. Yes the interface is the same, but your first example would
> have a PEOPLE file with an ADDRESS datafield.
>
> The second example would have a PEOPLE file with an ADDRESS-KEY
> datafield and an ADDRESS virtual field. From the point of the person
> using the query language, they would neither know nor care that the two
> ADDRESS fields are fundamentally different "under the bonnet".

In other words, the implementation is different ("under the bonnet") but the interface is the same.

Here's a question: let's imagine a giant nested data structure. You have records nested ten levels deep, and the data in each level is ten times as much as the level it's contained in.

Let's say you want to query only the top level, and not pull in all that extra stuff. Can you do that? What does the query look like? What if you want only 3 levels deep?

Is there a reference for the MV query language I could read somewhere?

> >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.
> >
> Putting constraints in the app not the database leads to smaller
> development teams.

I don't believe it. I'd believe that it only *works* with smaller development teams.

> >> 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.
> >
> So would I :-) But I want my constraints *optional*.

An optional constraint is a contradiction in terms.

What is it that makes you want it optional? What's an example of a rule you want enforced sometimes but not other times?

> >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.
> >
> Well, you saw my example about the Australian breweries? Where one
> brewery stole a march on the rest and hammered the lot in the market
> place - apart from the one MV-based brewery that responded quickly
> enough to ride up with them?

That's not a use-case, but it *is* a great success story.

I'm interested in lower-level, specific details. The nitty-gritty. Like, here's table 1 and here's table 2 and I wanted to figure out x, so I typed xxx and it was really easy and the comparable SQL is xxxxxxxxxx which is really hard.

> >Bring on the anecdotes!
>
> The story I like, where consultants spent SIX MONTHS tuning a complex
> query so's it ran faster than the MV system it was replacing - and when
> they crowed to management that the new system was 10% faster than the
> old system they were brought down to earth with a big bang as the guy
> supporting the MV system pointed out that was running on an ancient P90
> - the new system was a twin Xeon-800 box and surely it should be able to
> do better than just 10%? (Oh - and I'm prepared to bet dollars to cents
> that the MV query wasn't optimised AT ALL.)

Again, a nice story, but without the *specific* query and the specific tables, I don't learn much from it.

I guess a key thing I'm looking for is results that I can reproduce at home.

> Science has recently been surprised by the apparent existence of 5-quark
> bosons. I think investigating the relationship between "real data" and
> "relational tuples" (in other words, trying to formalise business
> analysis) might provide a few (to say the least) surprises ...

Can you propose a methodology? My best guess is that the question you are posing is meaningless.

> >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.
> >
> Anecdotally ... but there are apparently some pretty huge MV databases
> out there, and they haven't hit problems yet. At least, not ones
> attributable to the database - maybe the hardware isn't powerful enough,
> but relational would have hit the same problems a lot harder AND sooner.

How huge? My job involves working on a dataset that is measured in terabytes.

> Or redundancy, hardware scalability, what have you but all things that
> are external to the database.

Agreed.

> >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.
> >
> Exactly. So you see why we object when people say "relational MUST be
> right because it's based on mathematics". It's formal, sound,
> self-consistent, and ... :-)

Mmmm. That might be a fair criticism of this newsgroup as a whole, but I don't know if it would stick to me that well. I don't recall saying "relational MUST be right" at any point. I'm more along the lines of "I like how well relational handles many-to-many relationships."

Marshall Received on Sat Jul 10 2004 - 04:43:00 CEST