Re: Wishing trolls away

From: Bill H <wphaskett_at_THISISMUNGEDatt.net>
Date: Sat, 15 May 2004 15:17:02 GMT
Message-ID: <Nvqpc.54091$xw3.3242491_at_attbi_s04>


Lauri:

"Lauri Pietarinen" <lauri.pietarinen_at_atbusiness.com> wrote in message

> So what do you think the "magic formula" of Pick is when comparing
> to SQL? Is it one spesific feature, or is it a set of features?
> To put it another way, what should be added to SQL to give it
> the same advantages?

A simple description of an MV (Pick) model is: it is both a database and an application server.

Secondly, the nomenclature is the same as used by office staff: files, records, query, etc so it is easy to understand. One of the striking features about computing environments is their constant misuse of language to describe itself; so normal people are left dumfounded when techno-geeks describe simple tasks using familiar language in unfamiliar ways.

Thirdly, from a programming perspective, data is loosly typed. This makes it easy for people to program who actually know something about the business (as MV is used mostly by businesses). This dramatically reduces complexity and opens up the environment to a different style of programming.

> > > And on the reporting side, I think products such as Business Objects
> > > and Cognos Impromptu provide excellent (integrated) capabilities and
> > > that is where the RM (and even SQL!) really shine.
> >
> > That is what I used to think (and speak on). Then I had and saw teams
of
> > software developers working to make companies productive with SQL-based
> > tools on SQL-DBMS's and the MV query language on MV databases. There
> > really is no comparison from an "end-user" standpoint.
>
> Can you give an example? Again, what were the features in the Pick
> environment that differentiated it from the SQL environment? What
> should be added to SQL so that it would be on par with Pick?

The MV (Pick) query language used to be called English (this can be good or bad). It is very easy for end-users (especially for English speaking end-users) to use. First one creates a vocabulary (a dictionary definition) of fields then uses this vocabulary in a query. There are no joins or anything else complicated to destroy the simple syntax: VERB FILENAME SELECTION-CRITERIA OUTPUT An example: LIST EMPLOYEES WITH SSAN LIKE "3..." NAME SSAN PAYRATE will give us output of employees whose social security number starts with the number 3 and output their names, social security number, and payrate. Any joins, or other data complexity, is defined in the dictionary definition of the field (or virtual field), so the language remains simple. Received on Sat May 15 2004 - 17:17:02 CEST

Original text of this message