[rt-devel] thoughts: uniq attachment and multiple references?

[Bruce Campbell]

After my continuing saga with importing tickets (tip, turn off mysql
logging first lest you cause later embarressment), I'm struck by a blatent
waste of space in RT (and pretty much all ticketing systems that I've
seen).

To wit, duplicates are kept on the backend in duplicate/however many
copies.  This is a Bad Thing(tm) when you've got nearly a gig of data, and
suspect that you can save ~5% by keeping only one copy of a given message.
This is a nightmare when you know there might be another gig in a seperate
queue collecting routine reports to import into RT ;)

Looking at the 'Attachments' table, I think that you could redefine it as
follows:

	Table Attachments:
	id, TransactionID, Parent, MessageID, Subject, Filename,
	ContentType, ContentEncoding, *ContentID*, Headers, Creator,
	Created.

ContentID is then used as an index into another table (I know, more
indirection) to store the actual content (which the replaced field
'Content' current does).

	Table Content (no back references needed):
	id, Content (blob)

The coding changes would appear to be in RT/Attachment.pm Create(),
Content(), Quote(). (quite likely missed other bits, but code mentioning
Content seems to call the above routines happily.

Would this be a good/bad thing to be doing (ie, code up and provide
patches for, or has Bruce been visiting too many (Amsterdam) Coffee Shops
in his lunch break? ;)

-- 
                             Bruce Campbell                            RIPE
                                                                        NCC
                                                                 Operations