Re: [9fans] PQ - a Plan 9 way of relational database?

[cLIeNUX user <r@your_host.com>]

humbubba@smart.net
>This is a multi-part message in MIME format.
>--upas-dnkmsjugyrtaefkvjljmkvwmdf
>Content-Disposition: inline
>Content-Type: text/plain; charset="US-ASCII"
>Content-Transfer-Encoding: 7bit
>
>I was too late to enter this discussion, because have been engaged in
>other task, Japanese font. ^_^
>
>I began to see pq from the last day...  First of all, I was surprised these
>codes are too small to be expected as Relational database system...  However,
>along with proceeding my understanding, I was getting realize hmmm this
>is that, the Plan 9 way of dealing with database, everything resources are
>named files...
>
>Join could be very easy to Plan 9, yes, agreed.  Indexing could be done this way,
>agreed.  Record is considered as a line deliminated by a character, and the
>attribute is individual elements enclosed by such delimiters in this line.  The
>file can be called 'database'  in a normal sense.  Record lock is file lock, and
>we don't need any other mechanism for it, because fileserver can offer it.
>Yes, very interesting!
>
>In your implementation, numbers are treated by ascii digit number only?
>How about floating point number?
>Does it have some arithmetics such as plus, munus, multiple or <, > >=
>etc operators?
>
>Sorry, I'm not full understanding of your PQ yet.
>
>Kenji
>
>
>--upas-dnkmsjugyrtaefkvjljmkvwmdf
>Content-Type: message/rfc822
>Content-Disposition: inline
>
>Received: from granite.cias.osakafu-u.ac.jp ([192.168.1.3]) by granite.cias.osakafu-u.ac.jp; Thu Feb  8 15:19:13 JST 2001
>Received: from elmo.cias.osakafu-u.ac.jp (elmo.cias.osakafu-u.ac.jp [157.16.103.2])
>	by granite.cias.osakafu-u.ac.jp (8.9.3/8.9.3) with ESMTP id PAA02777;
>	Thu, 8 Feb 2001 15:22:01 +0900
>Received: from mail.cse.psu.edu (postfix@psuvax1.cse.psu.edu [130.203.4.6])
>	by elmo.cias.osakafu-u.ac.jp (8.9.3/3.7W-01020211) with ESMTP id PAA14357;
>	Thu, 8 Feb 2001 15:21:27 +0900 (JST)
>Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.18.6])
>	by mail.cse.psu.edu (CSE Mail Server) with ESMTP
>	id 0A2C9199F8; Thu,  8 Feb 2001 01:21:09 -0500 (EST)
>Received: from x.bell-labs.com (204.178.16.14.bell-labs.com [204.178.16.14])
>	by mail.cse.psu.edu (CSE Mail Server) with SMTP id E5988199E1
>	for <9fans@cse.psu.edu>; Thu,  8 Feb 2001 01:20:37 -0500 (EST)
>To: 9fans@cse.psu.edu
>Subject: Re: [9fans] So, once I've got the OS up how do I...
>From: geoff@x.bell-labs.com
>MIME-Version: 1.0
>Content-Type: text/plain; charset="UTF-8"
>Message-Id: <20010208062037.E5988199E1@mail.cse.psu.edu>
>Sender: 9fans-admin@cse.psu.edu
>Errors-To: 9fans-admin@cse.psu.edu
>X-BeenThere: 9fans@cse.psu.edu
>X-Mailman-Version: 2.0.1
>Precedence: bulk
>Reply-To: 9fans@cse.psu.edu
>List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu>
>List-Archive: <http://lists.cse.psu.edu/archives/9fans/>
>Date: Thu, 8 Feb 2001 01:20:19 -0500
>Content-Transfer-Encoding: quoted-printable
>X-MIME-Autoconverted: from 8bit to quoted-printable by granite.cias.osakafu-u.ac.jp id PAA02777
>
>Forgive me for pulling a Boyd or two.  This new-fangled RAM stuff is
>crap; it can't even retain its contents across a power outage of a few
>seconds, let alone hours.  Gimme that old core memory any day; I don't
>need particularly fast memory (or processors).  That was *real*
>technology.
>
>I would hope that we wouldn't saddle Plan 9 with a Real Commercial
>Database=E2=84=A2.  In thirty years of programming computers, I've never =
>seen
>a problem that I thought would be better solved using a database.  The
>Real Commercial Databases like Oracle seem to require massive machines
>to achieve even mediocre performance, they lock up your data in binary
>form, and require you to use some abortion like ODBC or SQL to get at
>*your* data.
>
>I can see the utility in using an index to look up a record quickly by
>key.  This doesn't require a Real Commercial Database, however.  And
>why would I want to have to fight my way through SQL or buy the
>largest machine Sun makes or hire a full-time DBA to maintain schema
>or pay an enormous licensing fee for the privilege?
>
>Seriously, can anybody explain why a rational person would buy a Real
>Commercial Database?  (`Because all the other lemmings are doing it'
>isn't a sufficiently-good answer.)  I've been waiting 25 years for
>such an answer and haven't got one yet.
>
>- ye olde codger (what ever happened to VSAM?)
>
>--upas-dnkmsjugyrtaefkvjljmkvwmdf--


I wrote a database recently for cLIeNUX mostly using Bash, awk and one or
two binaries. In heated arguments about whether it was a real RDBMS or not
I cited the Plan9 manpage for join. Real RDBMS, yes. Comparable to or
supplanting big commercial monster, no. Why not? Transactions. E-commerce.
Multi-user. SQL. Triggers. Mine is/has none of those. I learned a lot
about triggers in that argument. They look like the sort of thing a Forth
guy would learn to do without, but ecommerce is only so minimizable.

The heated argument was actually not over my own little unknown, but over
mySQL versus I forget what, PostgreSQL maybe. mySOL is faster, simpler,
lighter, and apparently not up to ecommerce.

I've wanted a lucid personal database on occaision for attacking large
source packages I want to modify, and I wrote the one I did for a client
for his email folders, which are huge due to a ebay/mailorder business. I
haven't used it for anything yet. I think I will though on my next major
bout with a big open source thing that's not quite how I want it. It
should be helpful. That's probably the scope of a Plan9 RDBMS. Bell Labs
is probably in a position to clarify the distinction betmeen that and
whatever you want to call Oracle, db2 et al. I'm not. The one in cLIeNUX
is somewhere between alpha and beta and is called PIRDE, Personal
Integrated Relational Database Environment. The "environment" is a shell
session with schema-specific state.

Rick Hohensee
www.clienux.com