Re: Storing derived and derivable data

"Kenneth Downs" <knode.wants.this_at_see.sigblock> wrote in message news:ue2ti3-u0a.ln1_at_pluto.downsfam.net...

> Another drawback is more of a balance question. Materializing derivations
> within the transaction lengthens the transaction, takes more space, and
> increases in some cases the chances of contention. But then the reads are
> fast. With a view, the transactions are kept shorter, at the price of an
> ever-increasing read cost as the complexity increases.
>

Hi Ken. Long Time no See. Welcome back.

It's going to take me a long time to go through the material you've pointed us to.

In the meantime, I'd like to understand your main point a little better. Oracle has a tool called a "Snapshot"
that was new to me on one of my projects. When the DBA described snapshots, my reaction was that it sounded like a materialized view. Her response was that that is exactly what it is.

In retrospect, I think my response was an oversimplification. Some transforms can be carried out in a snapshot that can't, to my knowledge, be implemented in a view. I've got two questions for you. First, is what I've just said true or not? Second, if true, is it relevant to the point you made in your earlier post?

> Finally, SQL itself is a piss-poor language in which to store the
> authoritative fundamental definition of derived data, so the view
statement
> itself can't be your method of definition. You need a better language in
> which to define the variations, and then you decide whether to use a view
> as an implementation method.
>

Well, I'm an eighty-twenty kind of guy myself. My attitude toward good tools with some defects is anathema in c.d.t. I've done some good things with SQL, and I'm not about to apologize to anyone in this group for doing that.

At the same time, it's worthwhile knowing what the features of a better language than SQL would be.

So, Ken, what makes SQL a piss-poor language?

> >
> > I like most of what you wrote in your normalization + automation
> > column, with only minor quibbles about the normalization issue. I,
> > too, believe that we should treat our metadata, including business
> > rules, as data.
>
> I wish I were more persuasive on this point. It seems so self-evident to
me
> that I often find myself at a loss to explain it.
>

I understand your frustration. You could shorten your argument down to the level of a slogan, like "theory IS practical". It might come out somthing like this: "software IS data, but it's just not expressed in the most usable form". Trouble is, to people who just want to run it, and not manage it, software IS expressed in the most usable form. I think that's where the disconnect is between you and those you wish you could persuade. Received on Sat May 06 2006 - 14:04:01 CEST