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

[okamoto@granite.cias.osakafu-u.ac.jp]

[-- Attachment #1: Type: text/plain, Size: 1112 bytes --]

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


[-- Attachment #2: Type: message/rfc822, Size: 2986 bytes --]

From: geoff@x.bell-labs.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] So, once I've got the OS up how do I...
Date: Thu, 8 Feb 2001 01:20:19 -0500
Message-ID: <20010208062037.E5988199E1@mail.cse.psu.edu>

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™.  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?)