I don't know if you saw my other post, but I've changed (but not committed)
the JDBC repository to store the message body separately in the file system
(using Avalon's stream repository).
I don't know if putting the message body into another table (put still in
the DB) is going to help vs just putting it in a DB. I guess I'm used to a
DB that does the indexing well enough that the size of the record doesn't
matter so much, although I do recognize sticking the entire message in the
same table as everything else somewhat violates traditional DB design.
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
----- Original Message -----
From: "M.P. Willems" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, July 31, 2001 11:01 AM
Subject: Re: Input for JDB Mail Repository
> ----- Original Message -----
> From: "Charles Benett" <[EMAIL PROTECTED]>
> To: "James Dev" <[EMAIL PROTECTED]>; "Jakarta-James User"
> <[EMAIL PROTECTED]>
> Sent: Tuesday, July 31, 2001 1:15 PM
> Subject: Input for JDB Mail Repository
>
>
> > In cvs proposal dir is Serge's JDBCMailRepository and
> > JDBCSpoolRepository.
> > Serge uses Mssql server with Inet Sprinta (I think) and I have got it
> > going with MySQL and the mm driver.
> > This is intended to replace the town db classses in James 1.2.1
> >
> > At the moment, they new classes need to be re-compiled for different
> > drivers and dbs.
> > I want to tidy up the config and move them into the main tree.
> > So I am looking for input from developers/ users.
> >
> > 1) At the moment the JDBCMailRepository (like the town repository) puts
> > all messages in one db table.
> > a) Would it be useful to allows different tables, e.g. one for spam
> > another for errors etc.?
> > b) If one had multiple tables, how likely is it that one would have them
> > in different dbs or on different machines?
> > c) If one had multiple tables, would we still want all POP3 inboxes to
> > be in one table or would per-user tables make sense?
> >
> > Any other suggestions re storing mail in a db would be welcome.
>
>
> Other suggestion:
> Maybe there is a argument for changing the message table structure, the
> records in the table "message" will be allowed to become bulky as a result
> of the defenition of the attribute "message body" , thus affecting
> performance and scalabillity.
> Maybe it's usefull to give some thoughts on putting those message body's
> into a seperate table , in order to improve performance, operational
> maintanance and if desirable allowing the assignment of storage area's to
> the table's.
>
>
> > Charles
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
