Comment One file per e-mail part is the only way to go (Score 1) 615
If you administer a corporate e-mail system, one thing you will find is that your mail system rapidly fills up with multiple copies of the same e-mails, most of them with uncompressed Excel spreadsheets weighing in at hundreds of kilobytes of wasted space.
Furthermore, if you store these things in databases or mbox-type flat files, you also find that your "incremental" backup tapes fill up with the same stuff.
One file per e-mail solves part of this problem. One file per MIME part would probably do it even better.
Sure, you can do the same thing with databases and fancy backup strategies, but why bother? If file systems aren't adequate to the struggle, use better ones. (Anyway, I'm not convinced of that -- if you're really concerned about inodes, change the setting on the partition which holds the mail. If you're concerned about the time it takes to read linearly through a directory, use directory trees.)
Databases always make me cringe. The number of times I've failed to restore Outlook mail files after they have been incompletely transferred over a network has convinced me to never again even think about database mail storage. Use a database for indexing if you really want to (although IMHO an SQL server is a ridiculous extravagance and waste of cycles for a database which will comfortably fit in less RAM than a typical screensaver), but make sure you can rederive it from the original data.
Breaking into down into single files makes everything simpler (starting with locking and going up from there.)
Probably too late to bother contributing and I'll bet all these points have been made already anyway, but I feel passionate about this. So there.
Rici
Furthermore, if you store these things in databases or mbox-type flat files, you also find that your "incremental" backup tapes fill up with the same stuff.
One file per e-mail solves part of this problem. One file per MIME part would probably do it even better.
Sure, you can do the same thing with databases and fancy backup strategies, but why bother? If file systems aren't adequate to the struggle, use better ones. (Anyway, I'm not convinced of that -- if you're really concerned about inodes, change the setting on the partition which holds the mail. If you're concerned about the time it takes to read linearly through a directory, use directory trees.)
Databases always make me cringe. The number of times I've failed to restore Outlook mail files after they have been incompletely transferred over a network has convinced me to never again even think about database mail storage. Use a database for indexing if you really want to (although IMHO an SQL server is a ridiculous extravagance and waste of cycles for a database which will comfortably fit in less RAM than a typical screensaver), but make sure you can rederive it from the original data.
Breaking into down into single files makes everything simpler (starting with locking and going up from there.)
Probably too late to bother contributing and I'll bet all these points have been made already anyway, but I feel passionate about this. So there.
Rici
