[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MySQL Secondary Select Method?
From: |
Romain Francoise |
Subject: |
Re: MySQL Secondary Select Method? |
Date: |
Sat, 13 Nov 2004 14:33:47 +0100 |
User-agent: |
Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) |
Brett Randall <usenet-gnus@ipsware.com> writes:
> A few days ago I wondered about the possibility of changing from an
> nnml secondary select method in gnus to a mysql one.
Several people over the years have asked for this, I have yet to see a
usable implementation. Try a Google Groups search for nnsql.el, there
are a few hits.
> Is this idea just way too inconceivable or is it something that could
> be done? Me and lisp just aren't good friends, so is there anyone who
> knows how this would go about being put together?
It could be done, but the approach has a few drawbacks:
1. Speed: without a native Emacs interface to MySQL, data access is
bound to be slower than the nnml file system based interface.
You'd have to use a socket-based Lisp-level communication with MySQL,
which would be somewhat inefficient and tricky to use
(asynchronously). See pg.el for a PostgreSQL example.
2. Storage: you would have to massively index your tables to get
reasonable speed and index files would grow as large as data files on
very large sets. And MySQL doesn't handle very large databases that
well, when you break the 2G barrier mysterious data corruption
happens...
3. Format: by storing all your data in a database, you are moving away
from an open storage format. With nnml, a Perl one-liner can convert
all your data to mbox which you can then use with a wealth of tools,
including webmail interfaces. In a database, all your data would be
in a proprietary, non-portable format.
Your time would probably be better spent improving the existing text
search tools like Namazu.
Cheers,
--
Romain Francoise <romain@orebokech.com> | There's no stronger wind than
it's a miracle -- http://orebokech.com/ | the one that blows down a
| lonesome railroad line.