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
