Speaking from a purely "part"/blob view, there are better solutions than a database for storing such information. An RDBMS is great for 95% of what DBMail does, but mail parts could be stored better. Doing so allows you to scale different parts of your system - I can guarantee that it's going to be more difficult to scale databases with massive blobs as opposed to just simple sets of relational data.
FYI for the OP, I'm looking at implementing mail part (so message content) storage in OpenStack's ObjectStore, and intend on having modular backends for storage. The first part of the puzzle though is dealing with message indexing - which needs to be offloaded to something/somewhere else. I'm half through writing up a proposal for the developers list on such an implementation. Regards, Chris Boulton Lead Engineer BigCommerce / Interspire Email: [email protected] Phone: +61 2 8003 4113 Web: http://www.bigcommerce.com Web: http://www.interspire.com On Mon, May 9, 2011 at 8:56 AM, Reindl Harald <[email protected]>wrote: > > Am 09.05.2011 00:35, schrieb DTK: > > Any plans on using MongoDB or something like it? > > why is everybody crazy about buzzwords? > > this is nice for a fast key/value-storage but totally > useless for relational data and even if the plain > mail data can put in such a structure you can not use > it on the MTA side for most complexer things > > so why use "nosql" - because it is a cool buzzword? > > before it would be finished to rewrite the whole dbmail for MonoDB > future versions of mysql will provide both combined instead > "relational sql" or "nonrelational nosql" > > > http://dev.mysql.com/tech-resources/articles/whats-new-in-mysql-5.6.html?sms_ss=twitter&at_xt=4da57923659f3bc7,0#nosql > > > _______________________________________________ > DBmail mailing list > [email protected] > http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail > >
_______________________________________________ DBmail mailing list [email protected] http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
