Re: MV and SQL

dawn wrote:
>
> > and it seems that some of the
> > features of a Pick MV system are:
> > - dynamically typed data
>
> Yes, I think that is an accurate term for it. It has a different
> approach to typing, or lack thereof, than any other environment I've
> been in. Everything is a string and you can convert it for output or
> processing to another type (similar to casting it).

TCL also works this way. You could perhaps draw some comparisons with Perl, but TCL would be the closest comparable.

Note that "dynamic typing" hasa fairly specific meaning (which I think applies here), which is that type correctness is not pre-checked, but instead checking is deferred until runtime. Dynamic typing has some significant benefits, the biggest of which is probably getting generic programming "for free" as it were, since all variables are generic. Other advantages are ease of implementation and simplicity. (Consider how complicated Java generics are, for comparison.)

Also note that it is harder to realize the advantages of static typing in a client-server world.

However, dynamic typing has some downside, as well. (Which is the same thing as saying that static typing has some upside.) Dynamic typing loses the documentary value that type annotations bring. Also, you can't do "typeful programming" where the programmer leans on the type system as a "proof assistant" for writing correct code. I believe that the value of this latter thing will only increase with time.

My opinion on the dynamic/static type split continues to be the same as my feeling about other splits, such as RM vs. OOP or MV vs. RM, which is that there must be a higher order truth that encompases both sides.

> > - persistence of data and procedures/libraries
> > - integrated development system
> > - portability
> > - parsimonious use of computing resources
>
> as well as developer time. Highly flexible over time.

Mmmmm, that's really more of a derived benefit, rather than a feature. (Small point.)

> > I don't know anything about the "query languages" of these systems and their
> > formal semantics.
>
> The LIST statement mentioned in the SOFACards is analogous to the SQL
> SELECT. The simple format is
>
> LIST filename fieldname fieldname
>
> It does not have only simple tables (rows & columns all populated) as
> output, but includes output like the one that will be in the example in
> my blog tomorrow.

Yah, I really would like to see more *specific examples* of queries from the MV people. It seems to me they have some queries that are, if nothing else, easier to specify than with SQL, and I'd like to have a better idea of what they are. This has been one of my chief frustrations with the debate.

I'm quite interested to dissect specific use-cases.

> > I'm particularly interested if they offer some kind of declarative query
> > language.
>
> Yes. Take a look at the poster at
> http://www.tincat-group.com/mv/familytree.html Along the right hand
> side are all of the names for this query language that I could find.
> Oddly enough, this language is quite consistent across all of these
> names, perhaps more standardized than SQL across vendors, although
> there is no standards body (there was an attempt at such in the 80's).
> Some people just call it ENGLISH, while most call it whatever their
> preferred vendor calls it. For example, I use UniData from IBM where I
> call it UniQuery and more recently OpenQM from Ladybridge Systems where
> I think they call it QMQuery. I think it would be great if I could
> refer to it by some one name. I was calling it MV Query, but there is
> a product named mvQuery. Ugh.

I don't think we care so much about the name; any generic term will do. Note that here we tend mostly to discuss "SQL" without specifying which vendor we mean.

> > If you want to compare the "data models" you need to compare the LANGUAGES,
> > not only the data structures.
>
> Yes, indeed. I'm pretty sure I have a year's worth of blogs just on
> topics related to data modeing.

You mean, already posted? URL please.

> > Some links that might interest you:
> > http://en.wikipedia.org/wiki/Plural_quantification
> > http://en.wikipedia.org/wiki/Second-order_logic
> > http://en.wikipedia.org/wiki/Regular_language
>
> I'll take a look. I haven't read these yet, but before I look at the
> second order language link, I'll note that Monadic Second Order Logic
> is provable, so it is not essential that a query language stick with
> first order logic.

Although I see advantages to having an always-halting query language, I don't consider it a requirement. There might be circumstances where we'd like the additional power and are willing to take on the additional
risks. (That risk is pretty small anyway.)

Marshall Received on Tue Jan 17 2006 - 01:03:27 CET