From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <66fc7b37342740fe4b0351051f9dbb35@quanstro.net>
To: 9fans@9fans.net
From: erik quanstrom <quanstro@quanstro.net>
Date: Thu, 27 Mar 2008 13:03:59 -0400
In-Reply-To: <3f0538b84c75cafb98ac711d83aa8518@csplan9.rit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] databases
Topicbox-Message-UUID: 845c4968-ead3-11e9-9d60-3106f5b1d025

> I haven't used PQ either.  In fact, has anyone used PQ in the last
> couple years?  I wouldn't trust OO to do my databases, but considering
> the Sinkhole of Support I'd be likely to experience with PQ (it's in
> sources/extra, it's old, it's unsupported), I'd be more inclined to
> write an interface to a remote postgresql or MySQL server, or try to
> port one of those.

while databases aren't in the unix/plan 9 cannon, i've had jobs
where we really did have a database of users, groups, subscriptions,
searches, documents, document collections and collection groups.
foreign keys a go go.  (mysql need not apply.)

on a small scale, this is plenty managable in a traditional filesystem.
when you need to track ~30 million documents and a couple hundred
million searches while insert rows in multiple tables transactionally,
a real database is awful nice.

while it would be nice to have a beefy plan 9 database, i wouldn't
bother porting one even if i needed it.  why not figure out what the
client protocol is and implement that for plan 9?

- erik