I also have to add that it seems that we will not only need the name of objects that use the CR, but also for objects for which it doesn't make sense to store them in the CR.
Yes, I agree entirely. My point is that the CR already has a name field and we want to avoid duplication - if people agree to an object name in acs_objects then we should make the CR use that field rather than maintain its own.
If we take the separate table approach then things like the overview field make more sense to me.
In this case wouldn't the logical way to define that separate table be to subtype acs_objects?
acs_object -> named_object ... this would separate out "skinny" non-named, non-overviewed objects from fancy named objects with (possibly) HTML overviews. Then your extra table would just be the type extension table for acs_object and bits of cr_item (name, description) could be folded in, making cr_item skinnier. At the cost of an extra join for cr_items I'm afraid but if enough were to go into the "named_object" field then you wouldn't need that join until you actually pull out a revision ... and they're often BLOB/CLOB so we don't expect great speed out of that operation anyway.
On the other hand pages summarizing objects by name would query against the named_objects type-specific table and not have to chew through internal objects that have no name ...
(BTW probably want to use MIME-type not html_p as does the CR)
Regarding non-revisioned objects ... I've already investigated the implication of setting a revisions revision_id == item_id and at least 95% of the CR code looks as though it would work unchanged. This would give us non-revisionable CR items that would only occupy one object rather than two. acs_object->cr_item->cr_revision rather than (acs_object->cr_item) + (acs_object->cr_revision). I've also toyed with the idea of always making the first revision this way and only creating separate cr_revision objects for versions after the first one ... this is for the future but my point is that I think we can make the CR "skinnier" without killing the advantages of using it.
Also I wasn't implying that 1 or 3 milliseconds was so fast that we could ignore the problem, I was merely providing a datapoint for folks. I'm not terribly interested in worrying about the speed of pages that list thousands of objects, though - we shouldn't have such pages and the fact that we have one such page today in the admin UI is a bug, not a feature IMO. But taking 1/10th of a second to call acs_object.name() for a page with 100 objects displayed is not a particularly short time.