----- Original Message ----- From: "Michael L. Barrow" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, March 11, 2002 4:54 AM Subject: RE: [courier-users] Re: Message Storage in a SQL database (ie MySQL)
> <quote who="Michael Kingsbury"> > > No, but you do have the benefit of moving the SQL database to hardware > > other than the mail server. I'd think that an SQL backend would allow > > for better clustering than flat files as well. > > You can do that now by moving your mail storage onto a dedicated fileserver > which is exported over the network via NFS (or whatever works best for you) > and then cluster/replicate the fileserver(s). > > Putting the message store in a database would merely complicate matters > terribly. Various folks are having problems getting Courier running on the > nice & clean filesystem model. Imagine what the list traffic would be like > if the message store were on a relational db!! :-) > > Perhaps this is a feature that could be added sometime in the future...if > people even wanted it. > > If you really want your mail in a database today, you can use M$ Exchange > or OpenWave's Intermail instead of Courier.... :-) Using an SQL database would increase the size of the file-storage by a factor of 3-10 most likely. It would have the added benefit of taking the disk I/O off of the mail server and onto the dbserver. However you'd want a db client that was very mature and stable. I wonder if there is even a db client that is as mature and stable as current local and networked filesystem drivers. Additionally, a good raid controller for local storage, or a good server nic for remote storage should handle most of your I/O anyways. IMHO, the only benefit would be features that really aren't part of the server anyways, these being features that allow close relationships amont items stored in the various maildirs. This may not even be that big of a benefit, because some MTAs can do this now. Outlook uses its PST file format, which really is a db, to keep relationship information about messages. For example: when you replied, if the message is flagged for follow-up, information about the attachments sent and the contacts that the message was sent to. While it sounds nice to be able to provide a standard interface so that all MTAs can do this, I don't see how you can do it w/out making big changes to IMAP (like MS did with MAPI). Besides, CPU is cheap now, so why not let the MTA's processors do that kind of work? So with these thoughts in mind, what are the benefits of an SQL backend that can't be solved by smarter MTAs, NFS mounts and/or better I/O hardware? Just my 2 cents worth. Matthew Nuzum _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
