Re: MV and SQL

x wrote:
> I have read the SOFA cards on your site

Great! I have some javascript user interface issues to address with those yet, but the information is at least out there.

> 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). But you are just working with tag-delimited strings, somewhat like XML, but with different programmatic structures (dynamic arrays sans metadata compared to the DOM) to work with the data.

> - composed types definable by a regular language
> - procedural programming

The client/server tools do provide access from Java, VB, and other languages, but the standard language used with the database for update purposes is DataBASIC.

> - persistence of data and procedures/libraries
> - integrated development system
> - portability
> - parsimonious use of computing resources

as well as developer time. Highly flexible over time.

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

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

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

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

Cheers! --dawn Received on Mon Jan 16 2006 - 18:52:55 CET