Re: MV and SQL

From: <michael_at_preece.net>
Date: 17 Jan 2006 19:04:03 -0800
Message-ID: <1137553443.300522.314580@f14g2000cwb.googlegroups.com>

Just a few comments imbedded - mostly to endorse Dawn's comments...

dawn wrote:

> Marshall Spight wrote:
> > dawn wrote:
> > >
> > > > and it seems that some of the
> > > > features of a Pick MV system are:
> > > > - dynamically typed data

One of the liberating aspects of the Pick environment. When you start from there you can decide for yourself, as a developer, whether you want to impose your own rules - and exactly what you'd like those rules to be. It all depends on the application. You can also choose not to impose rules - and parameterise things so that users can decide the rules (regarding data types and other things) for themselves by tweaking parameter settings - if it is prudent to allow that. Freedom. Once you get used to it it's oh so hard to give it up. Users tend to like a taste of it too - but then they often get hooked and develop an app of their own.

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

OT :- Were you aware that the Terminal Control Language - or TCL - is also the name of the language used at the command prompt in most Pick and Pick-like implementations? UniData - and probably Prime before it - had a number of petty differences to distinguish it from genuine/generic Pick, one of which was to call the MasterDictionary the VOCabulary file, and another was to call TCL ECL. I can't quite remember how they came by ECL - or what it is supposed to stand for. All veteran Pickies can say they "came from" either the generic Pick or the Prime side of the family. I'm from generic Pick and Dawn is from Prime - so maybe Dawn can shed more light on the origin of the name "ECL" and why it was seen to be an improvement on "TCL". There are a lot of little differences like that between implementations - most of which are irritatingly pointless. [Hmm... Almost deleted this paragraph.]

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

Did to me. A string is a string is a string. Unless you want it to be something else. ;)

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

There's that word again. The old double-edged sword. Wield it with care and it'll be your friend. It's the single most important aspect behind the success of so many Pick applications. It's also the reason many Pick apps are thrown together without a lot of thought and end up absolute garbage - and yet often succeed in spite of their shortcomings.

> >
> > 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 query language in Pick is just that - a query language. No great importance is placed on it. It's just one of a number of tools. No one would ever consider building entire applications around it. Powerful but not omnipotent. SQL is available with Pick as well, but again, it's considered as just another option. Unlike SQL-Relational. A significant difference that - imo.

> > > 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 recognise that. Many people with a background in, or at least more familiarity with, SQL-relational seem to me to place an inordinate amount of importance on the query language. The seperation between the logical and physical design is apparently demarked by SQL. In Pick there is no such clear-cut demarkation. The layer represented by SQL in an SQL-relational environment is represented by aspects of the application itself in a Pick enviroment. A Pick application consists of every layer from user interface down to IO-handling code. You can write a set of reusable modules once and deploy them with many different apps. Parameterisation then becomes a byword - even though you won't find it in the dictionary. At one end we can choose to use Java or dynamic HTML or VB (old-style) or .Net or... whatever. At the other end we can add all sorts of smarts into the file handling - including a DataAbstractionLayer, our own lock-handling mechanisms to supplement the standard pessimistic lock-handling, our own data publisher-subscriber schema, more levels of nesting than comes as standard with out-of-the-box Pick, integrity checking, anything... It's that freedom thing again.

> 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

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

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

I think we need to clarify this. On the one hand you have SQL - which underpins the whole of SQL-relational. On the Pick side you have a completely different toolkit - which includes SQL and the Pick query language - and many more tools, not least significant of which is DataBasic. I know people see the name "DataBasic" and learn that it was based on Dartmouth Basic and that it's a procedural language - and write it off. Don't. It's really very powerful in a Pick context. There's a synergy between the Pick environment and the language developed expressly for use in that environment. When people talk about the productivity of developers in a Pick environment and the rapidity with which they can adapt to changing requirements, they are not talking about the power of the query language (generally) - they are talking about applications written in DataBasic.

> > > 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
> http://www.tincat-group.com/mewsings -- the rest are brewing.

>


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

Cheers
Mike. Received on Tue Jan 17 2006 - 21:04:03 CST