> Thank you for the info. I haven't considered it before, but it makes
> sense to store large mail archives in SQL databases. I suppose it is
> one of the few ways to efficiently search such a large volume of data
> - much faster than searching Maildir or MBOX archives.
>
... and it lets you specify more than one search term too. Most decent
MUAs (I use Evolution) let you specify (optionally) the folder and a
match phrase for sender name(s) OR AND the subject. My query tool lets
me specify
(partial sender name OR address)
AND partial subject
AND phrase in plaintext parts of the message body
AND a date range.
Any of the four AND parts can be ignored if they would not help with
the search. The search tool uses a form-filling screen which allows any
or all of the ANDed search terms to be input, so its quite easy to use.
It can also let the user select e-mail addresses and subjects from
scrollable lists, though it does take a second or two to present these
lists.
In practice I usually specify the date range and one of sender name,
partial subject or partial plaintext phrase. I expected searching
message plaintext body parts for matching phrases would be rather slow
but it has turned out to be quite a bit faster than I'd expected.
Bottom line: using a database and a dedicated search tool gives users a
lot of flexibility in searching for and retrieving archived messages
and its a lot faster than scanning through their MUA's folders to find
old messages or discussions.
> I guess one aspect that is less than ideal is the fact that it
> wouldn't be possible to give archive access to users through their
> normal mail software interface - such as Thunderbird for example.
>
Something equivalent to my search tool should be easy enough for most
users to install and use.
My search tool only shows its user a list of matching messages.
Selecting any of these causes the selected message(s) to be sent to the
user as an attachment to a cover message. This serves two purposes:
(1) it allows the user to see the unmodified headers of the retrieved
message
(2) it means that I didn't have to faff round making the search tool
play nicely with displaying the message and decoding sattachments,
etc AND it means the user will see the retrieved message pretty
much exactly as it would have been if they'd received it directly.
My search tool is a Java application, so needs the Java JRE to be
installed on a user's PC, but it could equally easily have been a web-
based search tool written on PHP, Javascript or whatever. A;ll that
would need in addition would be webserver installed somewhere where it
can access the database. I run a local copy of the Apache webserver
with access to both it and my PostgreSQL database restricted to
computers on my LAN.
Martin
