Let us not forget that the really highend email systems such as Openwave Email Kx uses Oracle (AT&T Broadband, RoadRunner, Bell Canada and a host of other very large systems use the Openwave product), Microsofts highend smtp product uses MSSQL server, Novell's highend system (which outperforms most but is expensive) has a database at the backend. They're not saying what it is. I suspect its similar to the one they are using for eDirectory. they used to use Btrieve for everything, but they just recently started shipping MySQL with netware and dropped btrieve support. That leads me to believe that MySQL may be at the heart of a lot of their services. The next version of *cough* exchange server will have MSSQL at the backend. IBM mainframes use DB2 for the message store. A database makes a lot of sense for a mail server. The database folks have spent a lot of time developing techniques for finding information in files rapidly. There is also the issue of scaling to large files. Some databases are better than others with that. At the top of the heap are MySQL, Oracle and DB2. If you talk to the folks MySQL, namely Monty, he'll explain it, but has found that MySQL scales to large files better than Oracle does.
I could go on, but I like the idea of dbmail and I'm looking to implement it in my hosting business. It makes sense on a lot of different levels. The lack of documentation is a hinderance plus the fact that I've been working with Sendmail for years and now I'm learning postfix in addition to finding ways to implement spamassassin and anti-virus prior to dropping the message in the database. I've looked into all of the solutions and there is a good commercial product from the folks that wrote dnews and even it will use MySQL at the backend. I've gone on long enough, now back to your regularly scheduled discussion. Curtis On Tuesday 22 April 2003 10:38, Chris Nolan wrote: > Kiran N S wrote: > >Hi All, > >I am not an out and out techie, but would still like to know more about > > the stability of the PostgreSQL / MySQL database used in case of say, 10 > > / 25 / 50 / 100 / 500 / 1000 users. What are the db restoration processes > > executed and how, in case of PostgreSQL or say, McKoi / MySQL? Somebody, > > pls shed light on the issue. Can a stabler db like Oracle be used? > > PostgreSQL has pg_dump. MySQL has mysqldump. In both cases, you can > use 'em while the DB is running. pg_dump gives you a point-in-time > snapshot of the entire DB. If you're using the InnoDB table type in > MySQL, you can use the --single-transaction switch with mysqldump for > the same effect (make sure that you've got your isolation level set to > READ_COMMITED in your my.cnf file though). > > Resotration is easily handled with the command-line clients for each. > > >Another thing with the usage of MySQL is that it is not an RDBMS, leading > > to code complexities when you need to incorporate more effective > > productivity-oriented features along with the vanilla e-mail. Even a > > simple thing like, say, generating a report on number of e-mails sent to > > a particular account with timestamps can be a problem. What is the way > > out? > > Umm...errr...how exactly is MySQL *not* a relational database!?!? > > > From a business strategy point of view, will the introduction of > database-centric e-mail servers with/without messaging and groupware > functionalities result in a non-competitive offering in the market as > better flexibilities are offered through a file storage mechanism? Have > other players in the same space already analyzed the database route, > discovered it to be full of complexities and opted for a stabler file > storage model? Does a database approach speak of unsound strategy and fuzzy > R&D or is there light at the end of the tunnel? > > > There is definitely light at the end of the tunnel. > > Are you familiar with the reasons why database systems are such big > business? Basically, a RDBMS solves many of the problems associated with > storing stuff in lots of different files through it's fundamental > design. Problems of change control, syncronisation and versioning that > can cause headaches with distributed files are all solved through > database usage. > > If you're looking for a commercial implementation of "mail in a > database" check out Oracle's Collaboration Suite. It's built on top of > Oracle 9i and speaks IMAP4, POP3 and MAPI (sort of, enough to be Outlook > compatible). > > Additionally, the massive benefits available when your mail storage > backend is a database include, but are not in any way limited to: > > * Adding more storage becomes trivial and instantaneous - Just add > another partition to your database > * Backups can happen online, without interrupting anything > * Redundancy can be added without bringing down an already existing system > * The data store can be accessed concurrently by any app, without > needing to worry about file locking or low-level storage mechanisms > * Performance, performance, performance > * Filesystem limitations (file size limits, filename length limits, max > number of directory entries) all become basically null and void. > * Data safety! Even though we have XFS, JFS, EXT3 and the almighty > ReiserFS in the Linux world (with JFS coming to the BSD world real soon > and the other Unixes already having journaling...except that poor joke > excuse for a Unix SCO OpenServer), I'll take a transaction-based DB in > addition to those thanks! > * Security - As the FS is never touched, that's one less part of the OS > we (even though indirectly) expose to the world - security flaws in apps > can be rectified with less downtime than OS flaws in many cases. > > The list goes on. Storing stuff in a bunch of files is a simpler > concept, but unlike the simple concept that is the Unix paradigm storing > stuff in files can cause a lot of problems as you start wanting to do > more complex things. Of course, there is a blur between FS and DB > storage thanks to those idiots at Microsoft (with Access/Jet and that > pile of crap called FoxPro that the other pile of crap ACT! is built on > top of). > > I hope this helps somewhat! > > Chris > > >Look forward to hear from all you guys out there... > > > >Best regards, > > > >NS Kiran > >India. > >Cell Phone: +91-98861-12210 > >Land Phone: +91-80-333-6173 x-270 > > > >&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& > > > >"Sometimes you have to take the leap, and build your wings on the way > > down." - Kobi Yamada > > > >&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& > >_______________________________________________ > >Dbmail mailing list > >Dbmail@dbmail.org > >https://mailman.fastxs.nl/mailman/listinfo/dbmail > > _______________________________________________ > Dbmail mailing list > Dbmail@dbmail.org > https://mailman.fastxs.nl/mailman/listinfo/dbmail
