Hi !!
Some thoughs about database backends is some particular situations:
cache -> maybe it will be better to store the cache data on some other sort of file based database (plain text file, dbm, sqlite ...) This will be faster than using a server based relational database and will end with problems related to size of records.
addressbook -> it should have it's own database backend, many people would like to use it's ldap server for this (many already do that yet), maybe in adition or replacing the current per user addressbook
cache -> maybe it will be better to store the cache data on some other sort of file based database (plain text file, dbm, sqlite ...) This will be faster than using a server based relational database and will end with problems related to size of records.
Problems with the record sizes could probably be mitigated by changing the way the data is cached. I haven't looked into the code for this so i could be totally way off base and wrong and if so just call me on it =). The SQL queries should be pretty fast, flat files usually take longer to parse than doing an SQL query -- especially for large amounts of data/records.
If the caching was, for example, one record per message in a table of messages, that would probably help. Even splitting the message components up into headers (one table column per), body and attachments (if those are even cached). Each message would have additional metadata associated w it: roundcube user, imap server, folder, timestamp (for cache expiry).
Jeff
2005/10/28, David Saez Padros david@ols.es:
cache -> maybe it will be better to store the cache data on some other sort of file based database (plain text file, dbm, sqlite ...) This will be faster than using a server based relational database and will end with problems related to size of records.
I am agree. Temp files (in any format) is ok to me.
addressbook -> it should have it's own database backend, many people would like to use it's ldap server for this (many already do that yet), maybe in adition or replacing the current per user addressbook
I will propose 3 options:
1- (default) Per user addressbook (As it is now). 2- Per domain adressbook (similar to the current config, but a shared addressbook can be used). 3- LPAD or similar.
Using simoultaneously option 1 and 2 would be a good idea :-)
-- Andres Jimenez Dublin Institute For Advanced Studies
Hi !!
The SQL queries should be pretty fast, flat files usually take longer to parse than doing an SQL query -- especially for large amounts of data/records.
if you store each user's cache in a separate file the time need to load and parse it is by far quickly than any server based sql query
If the caching was, for example, one record per message in a table of messages, that would probably help. Even splitting the message components up into headers (one table column per), body and attachments (if those are even cached). Each message would have additional metadata associated w it: roundcube user, imap server, folder, timestamp (for cache expiry).
this will increase the number of records and the time need to process them. A cache should be as fast as possible, a database like dbm could do that faster (faster faster) than mysql
-
Andres Jimenez -
David Saez Padros -
Jeffrey Bacon