Communication of design, and structure is
one of the largest challenges any developer, and/or IT department faces. The
whole idea explained in the Mythical Man Month was that 12 developers X 1 month
is *much* less then 1 developer x 12 months. This is due to the issue of
increased communication *between* people (but hey, those meetings are fun!).
While the concept of communication in the Mythical Man Month was referring to
communication between developers, this general concept can be applied to all
people in a organization. The problem of communication exists for any kind of
procedure...be it software or otherwise. Hence, when one has to change the
software, the company procedures, reports, and training on how to retrieve a
phone number also will require a change. This *change* does not occur when data
is in a mV model.

Anyone with a perfect design would have
started out with two tables in SQL to take care of the phone number problem. My
point here is that SQL takes more skill, and better planning from the start. Too
bad we can't afford the best designer who does a perfect job the fist time
around. Too bad business have to change!...as next year we will need 5, or 6
phone numbers!

In the mV system, you can just start adding
additional phones numbers to that field...and away you go. The user who makes
this decision does not need a huge amount of training in relational data design,
nor even have to care about it. That is the beauty of a multi-valued system. It
models the real world with ease. I want another phone
number.....ok..done!

I had the challenge and pleasure of
converting an application from a pick mV structure to a SQL/vb application. When
you have some time, you can read more about this mv to SQL project . One of my *major* conclusions in this conversion project was that the
SQL design is *much* less forgiving, and thus requires far more skill is
required to get the *initial* design correct. Why? When you change the design in
SQL, it is far more likely that the code, and reports, and screens that edit the
data will have to be changed. This is not the case in a mv database.

Modifications over time represents a
significant cost of an application. Since a mv database can change with less
consequences, then it is obvious that the cost of maintenance is going to be
less.

Simple questions are simple.

In a mv database, a single record can
represent a whole invoice. In traditional environments, this is not possible and
the only way to represent a invoice to create a invoice object (assuming you are
using a language that lets you define and create objects). I found this out the
hard way when I tried to convert a mv application to sql/vb. It was only when I
started to create class objects could I approach anything near the flexibility
that was common in the mv environment. In a mv environment it is common to pass
around records from subroutine to subroutine. In a traditional system, the only
way to do this is to create an object. In fact, the average mv developer does
not think of a invoice as a object, but only as some record to play
with.

There are also user interface ramifications
when you have a structure that can represent a table. If the user makes a whole
bunch of changes while editing the invoice and then decides to "cancel" or undo,
you simply don't write the record back to disk. In a SQL system, this is huge
pain. You either have to load up a screen with the data from *several* tables.
Allow edits, then write back to the file, or wrap the whole screen in a
transaction (assuming your SQL engine has that feature). What is a dead simple
single record in mv becomes a real dance in a flat file system. By the
way...just how do you un-do your changes to a invoice? Anyone....since it sure
is pain for me!

Creating "objects" in a traditional system
does let one manipulate the invoice via code quite well. You can pass it from
routine to routine, and you can even add methods to the object. While these
objects do enable one to bring together a complex data structure, this complex
object structure does NOT work with the SQL query language. Thus, you get some
gain with objects...but these gains in modeling data only occurs in code. The
reason for this is that the invoice in a traditional system can only be
represented by *several* tables. In mv, this data is in general in one record.
By the way...xml also allows this type of table...

Here is a simple query example of what I
mean.

Lets assume we have a car lot. We also have
several car sales people. I simply want to know which sales man sold a blue, and
a red car last month. In fact, lets keep this question real simple as I don't
want to scare you about SQL anymore than one should. So, lets drop the month
idea...and lets just ask what sales man sold a blue and a red car.

In mv land we will have a table called
CarsSold. In that file it will contain a list of cars sold. This file may, or
may not have a relational link to the sales rep file (the sales reps may
actually be part of the file cars sold table). At any rate the syntax in a mv
system to ask this simple question is

I mean, how simple can you get? The above
returns the fields SalesRep, Make, Model and Color. Now, lets try the same thing
in SQL. Nine out of ten times when I ask people how this is done in SQL, the
user gets it wrong. In SQL, we would join the sales man table to the cars sold
table. The approach is as follows:

The above of course is wrong, since the
above returns any sales rep who sold a red OR a blue car. I am looking for a
sales rep who sold both a red AND sold a blue car (note, all cars in this
example are ONE color. So, we are NOT looking for a two color car here! A single
red car, and a single blue car). This type of question comes up all
the time. The same problem exists if we ask who sold cars in each of the last
two months. Or it could simply be what customers bought something in each of the
last two years. This type of question is one that requires multiple conditions
on a *related* table, but somehow must be grouped via a particular parent
record. SQL is terrible at this type of query.

The solution in SQL is to select a set of
data for red cars, and then test that set of data against people with blue cars
(yup...we are talking set theory here). The solution is not very pretty. While
there are number of ways to do this...below is the general approach. You really
need to use a nested select. If you come up with something substantially
better...please email it to me!

Of course if we need 3 conditions....then
things start to get totally out of hand.

I in no way want anyone to think that I
don't like SQL. In fact SQL ranks near the top in my in personal favorite list.
The reason for this is that I first learned to use SQL with FoxPro about 10
years ago. It is the ONLY thing in computers that I still use 10 years later. In
other words...SQL is a true data standard very much like HTML. Every new
database system that comes out will use, and support SQL. I have used SQL on a
ton of platforms, and languages. I see no chance of this changing. Learning SQL
is a long term investment in education. If you want to learn something useful
learn SQL. Learn it now, and you will still be using it 20 years
later.

Notes on mv-basic.

The programming language in mv is mv-basic.
While the mv-basic programming language is not extensible like vb is, it has a
number of things going for it.

Very loose data typing (in fact none is
enforced, and errors only occur when conversions fail).

Portable p-code engine (designed as cross
platform just like Java)

No concept of a end of file. You
open a file, and read a record. There is no concept of a end of file, or nor
is there a eof function. In general, there is also not file close
command!

As we continue the march towards
splitting data out of the application, the idea of a end of file becomes
totally outdated. In other words, we request a list of records...read the list
till exhausted and we are done. We really don't know, or even care where those
records came from...let alone if they actually have anything to do with the
idea that we reached some end of file. While much of the modern new languages
that pull data from a server are moving away from the idea of end of file, the
mv system is 30 years old. Way back then the idea of data processing
was to read punched cards to the end of file mark. As systems transformed from
cards to tape, and to *active* databases we have moved farther and farther
away from the idea of eof. This system had this idea correct, and that was in
a punched card era.

File opens do NOT generate a error when a
file does not exist in pick.

This has always been a pet peeve
of mine. If you open a file, most languages generate some type of trappable
error. To me, when a file open fails, that should not generate a trappable
error. The system should certainly have a means for informing one that the
file does not exist...but a trappable error?...that is crazy!. Trying to open
a file that does not exist does make a error in my book. No less than then a
search for name is not a error...but simply that the name does not exist. The
elegant approach that mv uses is to wrap all open commands in a nice then/else
structure.

The same goes for reading a
record. Again, in pick when a read for a non existing record occurs, it is the
ELSE clause of the command that executes. All records are written by a string
key id of YOUR choosing. There is NO auto number scheme built in. Whatever id
you use, this becomes a primary key.

Conclusion:

The processing speed of a mv system is
really that of how fast it can process strings. In the 1980's many mv systems
vendors had custom built micro code processors that would execute pick code
directly. Ultimate computers was one well known vendor that built boards that
you would shove into DEC and Honeywell machines that worked on this principal.
General Automation also played around with a what they called a Vulture board.
However, by the 1990's the speed of the Intel chip was closing the gap between
custom built "string" processors and a standard of the shelf chip. Soon, there
was no need for these custom built solutions as the standard Intel PC chip
became *much* faster.

The concepts and ideas contained in the
design of multi-valued systems really was a future vision of what a ideal data
system should be. Anyone who has experienced a mv database first hand will at
first react with very low impression of the system. As one begins to use, and
understand a mv system, one gets the sense of how simple, and yet how incredible
powerful such a system is. Anything that so is simple and yet so powerful for
sure marks the sign of a genius at work.

Some current popular mv vendors
are:

Pick systems (now raining data) with their
"d3" line of data products. They are the original mv company that licensed
their technology to many vendors. www.picksys.com