Re: Lucid statement of the MV vs RM position?

From: David Cressey <dcressey_at_verizon.net>
Date: Mon, 24 Apr 2006 21:27:52 GMT
Message-ID: <spb3g.2424$Ze.1552_at_trndny06>


<ralphbecket_at_gmail.com> wrote in message news:1145510297.269563.19460_at_j33g2000cwa.googlegroups.com...
> A number of people on this group are proponents of
> Pick (MultiValue) DBMS. I've been trying to find a
> definition for MultiValue to give me a better handle
> on the arguments MV types often advance against
> the relational model.
>
> As I understand it, an MV database is a collection
> of files, a file is a collection of records, records in
> a file all have the same structure, a record is indexed
> by a unique key, a record is a collection of fields, a
> field is a collection of (atomic?) values.

The best description of the data structure in a Pick file was given a few months ago, in here, by DonR, IIRC. By going to Google groups, you may be able to dredge it up. Or DonR, or the actual author, may be willing to give it again.

If you are familiar with the basics of data manipulation in files in the era before database managment systems, much of Pick will be familiar to you. My understanding, which comes from reading the description I've already mentioned, agrees for the most part with what you wrote.

Pick data is sotred in files. Files are made up of records. Records are set up for direct access. As I understand it, records are accessed by number, not by key. In any event, translating a key to a number is a small problem, probably offered as a service inside Pick. Records are made up of ASCII characters. Certain special characters are used to separate fields within records, and sub-fields within fields, and values within sub-fields.

So far this is just a rather simple minded specific case of a hierarchy. Nothing to offer scathing criticism about, but nothing to wax lyrical about either.

Where it starts to get interesting is in the following: many sub-fields consist of only one value, but this can be for one of two reasons: The first is that the context is such that multiple values would be meaningless.

The second is a case of a list with only one element in the list. Thus a pizza with onions on it will have only one value, "onions" in the appropriate place. A pizza with onions and mushrooms on it will have two values in the same place, separated by whatever the separator is.

This raises two questions in my mind:

First, how does one disambiguate between a list consisting of only one entry, and the entry itself. In other words how does one disambiguate between "onions" and "(onions)" since they both have the same representation in Pick.

The second question for me is how one distinguishes between a list used as a poor man's representation of a set, and a list used as a list, where placement in the list is supposed to carry information.

Thus the question is whether the list "(onions, mushrooms)" conveys the same information or different information than the list "(mushrooms, onions)".

The answer I keep getting from Pickies is (after I've stripped away the veneer) seems to be: "It's all in the mind of the programmer! Isn't that wonderful!"

My response is that it's not wonderful. The whole reason I migrated from files to databases was to get away from data whose description was buried in some other programmer's mind. If you think that keeping the ultimate key to decoding the data ought to be in the mind of the programmer, then I think you should stay away from databases. Either that or hang a suitable warning sign in front of any databases you have built.

>

> If that is correct, it seems to me that MV is an
> implementation technology and the RM is a logical
> formalism and that to compare the two is to compare
> apples and oranges.
>
> That said, debate on the topic still goes on and on
> in this group, so I assume I have failed to grasp
> something important about MV. Is there a clear,
> *concise* explanation somewhere of (a) a formal
> (preferably set theoretic) model of MV, and (b)
> how integrity constraints are expressed and enforced
> in an MV database?

Once again, "it's all in the mind of the programmer". Pick programmers are supposed to be so smart that they never create rogue programs or unintended data. I'll believe it when I see it. Received on Mon Apr 24 2006 - 23:27:52 CEST

Original text of this message