Re: Lucid statement of the MV vs RM position?
- From: "David Cressey" <dcressey@xxxxxxxxxxx>
- Date: Mon, 24 Apr 2006 21:27:52 GMT
<ralphbecket@xxxxxxxxx> wrote in message
news:1145510297.269563.19460@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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.
.
- Follow-Ups:
- References:
- Lucid statement of the MV vs RM position?
- From: ralphbecket
- Lucid statement of the MV vs RM position?
- Prev by Date: Re: Has E/R had a negative impact on db?
- Next by Date: Re: Lucid statement of the MV vs RM position?
- Previous by thread: Re: Lucid statement of the MV vs RM position?
- Next by thread: Re: Lucid statement of the MV vs RM position?
- Index(es):
Relevant Pages
|
