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

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

[geoff]

pq has been used mainly to query data that change relatively
infrequently (typically once or twice a day).  Adding real-time
incremental updates has been on the to-do list for pq for years.

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

[okamoto]

>Why not? Transactions. E-commerce.
>Multi-user. SQL. Triggers. Mine is/has none of those. I learned a lot

I suppose PQ (Phone Query?) would be designed mainly for read only
database.  Many usages of RDBMS may actually be this like.  :-)
However, yes, we should have the concept of transaction if we apply
this to multiple users who can update at anytime.
SQL and triggering are not so essential, but considered as cosmetics for
more user friendly RDBMS.

 From the naming, I suppose supported data types are limitted only to
string type.  However, adding more data types and more operations
other than '=' could be not so difficult.

As a conclusion, PQ should have concept of transaction first.
Am I wrong?

Kenji

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

[cLIeNUX user]

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

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

[okamoto]

[-- 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?)