> Messages stored in SQL??  You can have the users and passwords stored
> there, but there's really no reason at all to store the messages in
> SQL..  (I'm not even aware of a patch that can provide this functionality)

oops i was forgetting a bit confused there - maildir is the most reliable
for storing the messages! Just users & passwords that go in the database.

> Plus you have the ability to create an endless number of useless data
> reports!  How often people log in, average mail per user, etc..  *grin*

:) I like things like that... never too many graphs... and of course it will
make scripting so much easier without having to 'suexec' scripts to access
the data.

Thanks for the help,
David.

----- Original Message ----- 
From: "Jason 'XenoPhage' Frisvold" <[EMAIL PROTECTED]>
To: <toaster@shupp.org>
Sent: Thursday, January 06, 2005 1:51 AM
Subject: Re: [toaster] Latest toaster


> David wrote:
>
> >Thanks greatly for the very detailed instructions Bill, I will see how I
> >go... I hope that I can get simscan working with dspam because I would
like
> >virus scanning...
> >
> >
> I don't think simscan supports dspam yet..  It was talked about, but I'm
> not sure support was added yet..
>
> >Before I do I just thought it might be worth asking if there was a
> >disadvantage to doing things this way (having messages stored in sql
> >database instead of on disk)?
> >
> >
> Messages stored in SQL??  You can have the users and passwords stored
> there, but there's really no reason at all to store the messages in
> SQL..  (I'm not even aware of a patch that can provide this functionality)
>
> >I was interested in an sql backend because I thought that way the number
of
> >users would scale better and I was really worried about doing something
to
> >the filesystem that would corrupt/lose messages for potentially many
users
> >(I use a few CGI scripts to make administration easier). Are there
drawbacks
> >to doing things this way, other than the obvious increase in complexity
and
> >overhead ?
> >
> >
> SQL speeds things up a little when dealing with a large number of
> users.  It does cause extra complexity, and adds more failure points.
> But, it's fairly easy to replicate elsewhere, and re-building the
> database on a new machine is pretty simple.
>
> Plus you have the ability to create an endless number of useless data
> reports!  How often people log in, average mail per user, etc..  *grin*
>
> >David.
> >
> >
>
> -- 
> ---------------------------
> Jason 'XenoPhage' Frisvold
> Engine / Technology Programmer
> [EMAIL PROTECTED]
> RedHat Certified - RHCE # 803004140609871
> MySQL Pro Certified - ID# 207171862
> MySQL Core Certified - ID# 205982910
> ---------------------------
> "Something mysterious is formed, born in the silent void. Waiting alone
and unmoving, it is at once still and yet in constant motion. It is the
source of all programs. I do not know its name, so I will call it the Tao of
Programming."
>
>

Reply via email to