Alexandre Benson Smith wrote:

> Lester Caine wrote:
>> One thought would be - is the message content in a large character field
>> or in a blob? keeping large text fields in blobs helps in these sorts of
>> cases as the actual record can be a lot smaller, and more will fit on a
>> 'page' in storage. You only need to access the 'content' once you have
>> identified the header records.
>>
>
> Bu we must remember that small BLOB's that fits on the page are stored
> directly with the record...

How many emails are small these days ;)

But I would be interested to see some comments about the possible speed
advantages of the core data being in small length records, with details
like the full email address and the like in a secondary table and
content in blobs.

I prefer to use numeric 'user_ids' and similar more 'relational'
processing to keep the big tables as 'tight as possible. No need to have
a 256 character email field when a bigint to another table will do the
same job? In Elric's case, the subject field is probably best in the the
main record, but the sender and recipient fields may be better as simple
id's where you are only looking for a sender view or a recipient view?

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php