Don, that subtyping sounds more or less exactly like what i originally intended with my proposal of the extra table!!
I'm personally not afraid at all to maintain the naming information in cr_items and my extra table acs_objects_description, because we could use a trigger to copy the data from cr_items to the other table. Ok, it would mean redundant information but it would speed up queries in the CR, i assume (selects are by far more common than inserts/updates, so i think it's more important to focus on fast select queries). The bottom line to this would be: It's not important at all whether a package stores a copy of the object names in their own tables as long as it makes sure that the acs_objects_description table is always uptodate, although i totally agree with you in saying that the datamodel should be normalized if and where possible, but in the end that shouldn't lead to expensive queries if avoidable.
Attempts to cut down the size of CR tables are always good, i think!
PS: I want to clarify that the mailing list objects mentioned above are just objects each describing a mailing list, i didn't mean actual mailing list postings.
PPS: I thought about mime-types, but i thought that when displaying an object in a list of objects the object overview could only be either text or html, but if other scenarios come to your mind, then i would also opt for a mime_type column.
