Hey Dawn,
I note that your speculative, discursive style of essay hasn't been
received with much favor here. Would you consider another
approach? Would you consider the possibility of addressing
specific problems and providing specific solutions? You could,
for example, pick some common problem domain, invent a
conceptual schema, propose a logical schema in an MV approach
and a SQL approach (and possibly a Tutorial D approach.)
The SQL you come up with could perhaps be polished by
other people; maybe you could use some of your MV
acquaintances to polish the MV queries.
For example, I often think of problems in terms of a schema
with Customers, Invoices, and InvoiceLineItems. These are
familiar to anyone who has ever bought anything, so they
have the advantage of being a common ground for discussion.
(As well as being a very real-world application of data
management.)
One problem I have with a lot of your posts is that they are
very abstract and nebulous. We traded lists of questions a
short time ago, and I couldn't help but notice that most of
my questions had definite answers, and most of yours didn't.
This idea would make the discussion more concrete. If you
have the courage of your convictions, you should to be able
to demonstrate a variety of situations where MV works better
in the small, rather than just giving anecdotes about how well
you feel it works in the unmanageable-to-compare large.
It wouldn't even have to be a particularly theory-based
dialog. Just propose a problem, build a schema in MV
and SQL, build some challenging queries in MV and SQL.
MV does have a fairly standardized query language, does
it not?
What do you think?
