Null columns do take space in PostgreSQL - there's per-row metadata that is stored along with the data itself. In general per-row costs in PG are considerably higher than in Oracle. Per-seat costs are far lower, however :)
Essentially the various name_methods declared for various types just return a type-specific name field. This is why creating a view could easily provide the abstraction necessary for a top-level page to grab information about a particular object in the system. Assuming we really need to do this for non-content objects in a general way and that the current solution is really unsuitable.
We could speed the acs_objects.name() itself by declaring that name_methods are not inherited ... but my guess is the big expense comes from the "execute" command rather than the query.
The problem with moving stuff to a generic descriptions table is that type-specific pages - say the group admin pages - need to join with the description table as well as the type specific table in order to do its job. You've traded off speed in one place for less speed in another.
As to overuse of the object system itself ... well, if relational segments aren't objects, then one of three things become true:
1. You can't grant permissions to (say) "all Professors of Class Foo" without expanding the rel_seg and assigning the permission to each member, and without providing triggers to maintain consistency when members are added or removed.
2. Permissions are rewritten to take (table name, key) pairs again like in 3.x.
3. We don't require object_ids to actually point to acs_objects, i.e. we can have objects without the acs_objects metadata. This would be radical ... maintain the flat key space so system-wide concepts like permissions work. One could make the argument that the= minimal level of auditing provided by acs_objects should be optional, after all.
On the other hands I freely admit that each row in a relationship rarely needs to be an object. There is certainly some overuse of objects in the toolkit's implementation. I just feel like you picked a bad example.
I keep hearing arguments about the evils of the content repository but I don't see people actually running into problems in practice. I do have a scheme in mind that would allow non-versionable entries into the content repository, meaning there'd only be one object for the item-revision pair. It turns out that nearly all of the code looks like it would work with such a hack. If we provided both versionable and non-versionable content, along with an enhanced and much easier to use Tcl API, would people quit picking on the CR?
