From mboxrd@z Thu Jan  1 00:00:00 1970
Message-Id: <200102081857.LAA20130@dns.irm.r9.fws.gov>
To: 9fans@cse.psu.edu
Subject: [9fans] Plan9 Relational Databases
From: "Mark Otto" <Mark_Otto@FWS.Gov>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Date: Thu,  8 Feb 2001 13:57:51 -0500
Topicbox-Message-UUID: 5e801800-eac9-11e9-9e20-41e7f4b1d025

Geoff touches on some interesting points.

Why use relational databases (RDBs)?
I think RDBs are useful.  If you set up your data as relational
tables(one table describing a one-to-one relationship, two tables
describing a one-to-many relationship, and three tables describing a
many-to-many relationship), you can be assured that your data is
consistent and can be manipulated with a few simple operations.  Why
make a new format and tools for each data set.  Also, and improvement
in any of the RDB tools would improve the performance of all the
databases.  Someone know RDB basics could make their way through
/lib/vgadb or /lib/ndb/local with basic RDB tools without knowing
their special formats.  They could be manipulated without specific
tools too.  The down side is that what is concisely in one table would
be spread over many tables (still in ASCII or unicode) and in some
description of the relation between the tables.

Why use SQL?
On one hand, I agree, why have another proprietary format to convert
in and out of and interactive language to learn and to get into and
out of?  I used a version of /rdb ([www.rdb.com]) you have to look
past the fact that they are rabid UNIX fans), a RDB Management System
(RDBMS) that extended unix commands do the SQL selects, where,
expressions, joins, order bys, and group bys.  Col selected and
rearraigned columns, row selected rows, compute provided a front-end
to awk to allow the straight forward use of column names, join merged
files, sort, etc.  Each of the commands input and output ascii files.
There was only ve, a vi type editor to input and check tables as an
RDBMS might.  (Acme could provide a much better interface for this.)
The file permissions provided the security.  One could mimic SQL with
unix commands piped together.  Their argument was that computer and
versions of unix where getting so fast that the basic OS could do most
of the work.  Then you use already familiar other UNIX commands to
handle any other tasks (say tbl and troff to present tables).  There
was getting in and out of the system or data in and out.  (But, maybe
this is what Steve Kilbane, 2000-July.txt, was warning against.)

I use the Bell Labs S, (actually the freeware R, a derivative of
Splus), which is a nice language to do statistical analysis and
graphing.  It still has the hassles of getting data in and out of it
and getting in and out of the interpreter.  A /rdb system or `little
language' might be a better approach.

On the other hand, in SQL you can specify all the manipulations
(selects, joins, sorts, ...)  in one command without having to
consider the step by step way that they should be carried out.  The
system should figure the most efficient way to execute the steps and
store the data.  Once the tables and the relations (keys) among them
are defined, the manipulations are straight forward (E.  F. Codd's
relational calculus that describes RDBs is elegant).

A couple of months ago, Bill Staniewicz asked about what RDBMSs are
used in plan9 if any.  I didn't see anyone respond to this, but all I
have seen is the following:

1997-September.txt: G. David Butler discussed adding transaction
semantics to plan9 and 9p to help develop distributed databases.  (He
seems to have dropped off the face of the earth after version 3 came
out.  He sounded like he wanted to market plan9 version 3 with these
extensions.  I don't know whatever happened with this.)

2000-August.txt: Stephan Harris and Nick Gorham talked about making
Postgress a stand alone database.

2000-October.txt: Kenji Okamoto
([http://basalt.cias.osakafu-u.ac.jp/plan9]) made a Postgres (version
4) client monitor.

2001-January.txt: Matt Heath pointed out a linux project to make MySQL
into a file server ([http://no.spam.ee/~tonu/mysqlfs.html]).  They
make the each data item a file with the rows, columns, and tables as
directories.  To me, this is taking the fileserver idea too far.  With
tables, each row has the same columns, hierarchical filesystems do not
have to maintain that consistency.  I think an FS where the database
is directory and the schema, tables, and queries are files would
better.

Do others have an idea of what a plan9 RDB FS should look like?

Mark