Re: MV and SQL

From: dawn <>
Date: 17 Jan 2006 09:19:41 -0800
Message-ID: <>

Marshall Spight wrote:
> 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.

Yes, it is definitely the case that in the languages packaged with MV, there is no compile-time type checking. However, with the DBMS itself, one might say that there is no checking at all. The type checking will be related to the language used with the DBMS. Saying that MV is dynamically typed might be like saying that XML files without the dtd or xsd have dynamic typing. Did that make sense?

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

Yes. There are pros and cons to both approaches. What is the difference between dynamic typing and the more recently-coined duck typing?

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

Having done Java development, as well as procedural languages, I found it disturbing to start learning JavaScript (and more recently PHP) but they are growing on me. You can write good or bad code in any language, but Java seems to promote better practices with its strong typing.

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

That works for me. While we are still seeing in a mirror darkly, however, some choices are easier to make than others. The typing question is one that I keep waffling on. I'm now enjoying dynamic typing, but feeling that it might be like eating junk food.

> > > - 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 consider maintainability a feature, but I suppose it goes in what used to be called "non-functional requirements."

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

I have a little working query and result set in the example in my blog this week, and will be getting more down the road. While the query language is highly productive for someone using it, it requires procedural code in virtual fields behind the scenes. You cannot simply have your database and the query language only and then get every possible query out of the database, although it sometimes appears that way to end-users. Someone has to fashion each logical view (logical file) with the right vocabulary, sometimes writing procedural code (somewhat analogous to stored procedures) as the logic behind an attribute (virtual field). Security is also an issue in MV systems, with the security managed by the vocabulary files to which individuals have access (not a highly scalable approach so users come up with alternatives).

> It seems to me they have some queries
> that are, if nothing else, easier to specify than with SQL,

Yes, it is a more user-friendly language in many respects.

> 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 had said I would come through with examples, so I've taken up coding and will give examples in the blog as I have them. There is a learning curve for me, however, so you could download a U2 manual from IBM (such as UniQuery for the UniData database). If you look and have trouble finding one, let me know.

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

I'll try to help with that. Here is the main concept that is hard for a SQL-thinking person to find appealing --

You can only write a query against a single logical view at a time and that view looks like a single list of attributes all associated with a SINGLE ENTITY. That does not mean that all data need to come from the same file/table. But it seemed really dumb to me when I started that I could only ask a question of a single entity at a time. It turned out that this is one of the things that makes the query language so easy. It is easier to shop for data because your catalog of data is so nicely presented.

They know what they can see through a People entity (often the entities are plural as the query language reads more like English then), through the Orders entity, and through the Accounts entity. Some users will write all of their queries against a single entity, always seeing things from the perspective and vocabularly of an Orders entity (file), for example, pulling in other data by way of that vocabulary.

LIST ORDERS CUSTOMER_NAME ORDER_DATE WITH CUSTOMER_STATE = "MI" While others will write theirs from the perspective of another entity

LIST CUSTOMERS CUSTOMER_NAME ORDER_DATES WITH CUSTOMER_STATE = "MI" Notice the slight difference in vocabulary where when you look through the vocabulary of the customer entity, you see orders, plural.

> > > I'm particularly interested if they offer some kind of declarative query
> > > language.
> >
> > Yes. Take a look at the poster at
> > 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.

Yes, but there is a point here. It is really difficult to talk about this MV query language because it has no one name, but lots of vendor-specific names.

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

No, just the first two are posted at -- the rest are brewing.

> > > Some links that might interest you:
> > >
> > >
> > >
> >
> > 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 - 18:19:41 CET

Original text of this message