Re: MV and SQL

Hi

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.

.

Relevant Pages

  • Re: MV and SQL
    ... >> approach to typing, or lack thereof, than any other environment I've ... > Note that "dynamic typing" hasa fairly specific meaning ... be related to the language used with the DBMS. ... that this is one of the things that makes the query language so easy. ...
    (comp.databases.theory)
  • Re: MV and SQL
    ... >> perform enquiries on it using the query language then, again, how the ... > Are you sure that a column in Pick is equivalent to a column in an SQL table ... If you had some bizarre need to do this in a Pick DBMS though, ... > Besides the query language of Pick what other ways do ...
    (comp.databases.theory)
  • Re: MV and SQL
    ... >> perform enquiries on it using the query language then, again, how the ... > Are you sure that a column in Pick is equivalent to a column in an SQL table ... If you had some bizarre need to do this in a Pick DBMS though, ... > Besides the query language of Pick what other ways do ...
    (comp.databases.theory)
  • Re: MV and SQL
    ... >> perform enquiries on it using the query language then, again, how the ... > Are you sure that a column in Pick is equivalent to a column in an SQL table ... If you had some bizarre need to do this in a Pick DBMS though, ... > Besides the query language of Pick what other ways do ...
    (comp.databases.theory)
  • Design of a URL encoded language to specify sets of files on a WebDAV server
    ... I'm currently in the process of designing a language which will be used ... There will be a more verbose query language also ... One way of specifying search criteria in MetaFS is by using a dynamic ... Boolean Logic Engine ...
    (comp.lang.python)