Thread: mV database tools

On Wed, 2002-05-01 at 19:37, Arthur@LinkLine.com wrote:

> I also did some internet research on the subject of "multi valued"
database theory.  I know that this is the basis for the "Pick" database
system

For those who aren't familiar with PICK, it is an untyped database
(apart from weak types provided by a separate dictionary - advisory but
not enforced).  All records must have a single key, by which the record
is retrieved. Database records are divided into "attributes" by
CHAR(254), fields are subdivided into "values" by CHAR(253) and values
can be further sub-divided into "subvalues" by CHAR(252).  When records
are listed, second and subsequent values are presented on separate lines
within their columns.

In a PICK application, it would be common to have a set up such as:

CUSTOMERS file: key=id record=name|address1^address2^...|...|ordernumber1^ordernumber2^...
(using | for CHAR(254) and ^ for CHAR(253))

where the whole address is in one field, with each address line in a
separate value, and there is another field listing the order numbers
(record keys in CUST_ORDERS) of all outstanding orders, again as
separate values.

Then you could use the following commands (this is not SQL, of course):
SELECT CUSTOMERS WITH ID = "C23" SAVING ORDNOSSORT CUST_ORDERS

to list all the outstanding orders for custoemr C23.

The advantages of Pick are that it is very easy to program; the
corresponding disadvantage is that it is a very undisciplined
environment.  It is necessary for the programmer to remember to update
that list of order keys whenever an order is created or deleted. (Some
recent implementations now support triggers, I think.)

I suppose arrays are PostgreSQL's equivalent of multi-valued data (is it
possible to have arrays of arrays?)  So it could be argued that
PostgreSQL already provides part of what Arthur wants.

--
Oliver Elphick                                Oliver.Elphick@lfix.co.uk
Isle of Wight                              http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839  932A 614D 4C34 3E1D 0C1C
    "For if ye forgive men their trespasses, your heavenly      Father will also forgive you; But if ye forgive not
men their trespasses, neither will your Father forgive     your trespasses."         Matthew 6:14,15  

> I suppose arrays are PostgreSQL's equivalent of multi-valued data (is it
> possible to have arrays of arrays?)  So it could be argued that
> PostgreSQL already provides part of what Arthur wants.

It seems to me that there would be a whopping lot of value to the exercise of 
figuring out some way of "layering" MVD on top of a relational database, even 
if only to provide something sufficiently analytical to cope with the 
perpetual claims of:
 "MultiValued Databases are Vastly, Spectacularly, the Bestest Kind of  Database ever imagined in the universe!  No,
reallythey are!"
 

It might not be necessary to go all the way to fully layering such a thing atop PostgreSQL, although it would be a nice
riposteto be able to respond with:
 
 "Been there, done that.  Of _COURSE_ PostgreSQL supports MultiValue."
--
(reverse (concatenate 'string "gro.gultn@" "enworbbc"))
http://www.cbbrowne.com/info/lisp.html
Including a destination in the CC list that will cause the recipients'
mailer to blow out is a good way to stifle dissent.
-- from the Symbolics Guidelines for Sending Mail

-- 
(reverse (concatenate 'string "ac.notelrac.teneerf@" "454aa"))
http://www.cbbrowne.com/info/spreadsheets.html
"Starting a project in C/C++ is a premature optimization."
-- Peter Jensen

> "Arthur@LinkLine.com" wrote:
> 
> Dear Team,
> 
> I have been monitoring this list for quite some time now and have been
> studying PostGreSQL for a while.  I also did some internet research on the
> subject of "multi valued" database theory.  I know that this is the basis for
> the "Pick" database system, FileMaker Pro, "D3", and a few other database
> systems.  After carefully reviewing the theoretical arguments in favor of
> this type of database, I am thoroughly convinced that there are certain
> advantages to it that will never be matched by a traditional "relational
> database".
> 
> I won't waste your time in reviewing the technical advantages here, because
> you can do your own research.  However, I will say that it is obvious to me
> that an mV database will be an integral part of any truly practical AI
> robotics system.  It will probably be necessary to "marry" the technologies
> of both relational databases and mV databases in such a system.

The idea of a multi-view database is interesting and all, but hardly a next
leap in database theory. It is nothing more than using an addressable array
within PostgreSQL, and PostgreSQL has contributed functions for just these
sorts of operations.

The syntax may be different than you would wish, but with the same result. It
seems that mu

> 
> IMHO, this is something that you, as the leaders in the most advanced
> database system ever developed, should carefully consider.  The Linux
> community needs to be aware of the special advantages that an mV database
> offers, the way to interface an mV system with a traditional RDBMS, and the
> potential application theory as it relates to AI systems.
> 
> We, as a community of leaders in GPL'd software need to make sure that this
> technology is part of the "knowledge base" of our community.  Thanks for
> listening.
> 
> Arthur

mlw wrote:
> 
> > "Arthur@LinkLine.com" wrote:
> >
> > Dear Team,
> >
> > I have been monitoring this list for quite some time now and have been
> > studying PostGreSQL for a while.  I also did some internet research on the
> > subject of "multi valued" database theory.  I know that this is the basis for
> > the "Pick" database system, FileMaker Pro, "D3", and a few other database
> > systems.  After carefully reviewing the theoretical arguments in favor of
> > this type of database, I am thoroughly convinced that there are certain
> > advantages to it that will never be matched by a traditional "relational
> > database".
> >
> > I won't waste your time in reviewing the technical advantages here, because
> > you can do your own research.  However, I will say that it is obvious to me
> > that an mV database will be an integral part of any truly practical AI
> > robotics system.  It will probably be necessary to "marry" the technologies
> > of both relational databases and mV databases in such a system.
> 
> The idea of a multi-view database is interesting and all, but hardly a next
> leap in database theory. It is nothing more than using an addressable array
> within PostgreSQL, and PostgreSQL has contributed functions for just these
> sorts of operations.
> 
> The syntax may be different than you would wish, but with the same result. It
> seems that muDoh!! pressed send!!

It seems that a multivalue database can be implemented on top of PostgreSQL,
where as a full relational database can not be implemented on top of an MVDB.