From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu From: okamoto@granite.cias.osakafu-u.ac.jp MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-dnkmsjugyrtaefkvjljmkvwmdf" Message-Id: <20010219041407.203F7199E4@mail.cse.psu.edu> Subject: [9fans] PQ - a Plan 9 way of relational database? Date: Mon, 19 Feb 2001 13:13:28 +0900 Topicbox-Message-UUID: 67558eb0-eac9-11e9-9e20-41e7f4b1d025 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: 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--