From mboxrd@z Thu Jan  1 00:00:00 1970
Message-Id: <3.0.5.32.20020122150201.015acb08@mail.real.com>
To: 9fans@cse.psu.edu, 9fans@cse.psu.edu
From: skipt@real.com
Subject: Re: [9fans] Getting started in Plan9 - help
In-Reply-To: <20020121203946.49EA219A27@mail.cse.psu.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 22 Jan 2002 15:02:01 -0800
Topicbox-Message-UUID: 41413836-eaca-11e9-9e20-41e7f4b1d025

unity, a package that could be found at AT&T Toolchest long ago, kind of
did relational data management the "unix" way. My memory is not very clear
on this, but I recall it used text files, with hash index files for fast searches, and
I think it embedded the dictionary as the first (comment) line of
each file. You could use grep and awk, etc. I used it with some large data
sets, and it worked correctly and was fast. (I just checked, Lucent SSG sells it)

It is much harder to tastefully map a  table (matrix structure) to
a filesystem (a tree).

At 03:39 PM 1/21/2002 -0500, Russ Cox wrote:
>I think it might be neat to build a small number
>of little programs that parse and reemit sql queries.
>Thus you could use normal shell pipelines to do database
>queries but since you're passing _queries_ and not _output_
>through the pipes, you still reap the benefits of
>query optimization.  Just like the old /acme/edit scripts.
>
>I don't remember enough of the SQL syntax to
>reparse your query into an exact shell pipeline, but
>the idea is you could do something like
>
>	sql/grep 'Car%' pages.title | sql/join section pages.idx |
>	sql/p
>
>Sql/p would behave like the acme p, actually executing
>the query to produce output.
>
>Of course, if there isn't much data, moving it into
>the file system might be an even better solution.
>
>Russ
>
>