On Tue, 2005-04-19 at 22:53 +0300, listmember wrote: > Take, for example, From, Data, Sender, To, CC, Retun Path > fields for each message. If DBMail had parsed these fields > and stored them in a separate table, a lot of searches could > be speeded up.
Not necessarily. RFC822 parsing is a nightmare, and INDEX time is rather high for them. Besides the IMAP SEARCH BODY[HEADER.FIELDS ()] method, there wouldn't be any speedup [to IMAP clients] at all- furthermore, there aren't many clients that can take advantage of indexes there. I'm not saying it shouldn't be done, I'm just saying the immediate usefulness isn't search-speed. But I would say that trying to 1NF RFC822 _would_ be difficult, and actually unnecessary. It'd probably be much better/easier to have a table of: dbmail_rfc822preparsed(mailbox_idnr, message_idnr, LOWER(header), value); and while not pretty, modern database servers will have a much easier time of this, and db-interfacing code will be much easier for the current db-interface won't have to be extended to support dynamically generated/escaped relation-names. There's already some support for header-parsing in trunk (IIRC), so it might not actually be that difficult to do here. IT _WILL_ however make your charting problems a bit more difficult to express. -- Internet Connection High Quality Web Hosting http://www.internetconnection.net/
