<blockquote> Do all objects in the system really require this much information?
</blockquote>
No, in a system where rel_segment is an object with its own entry
in acs_objects this information doesn't belong to acs_objects.
I don't like the idea of having a bunch of columns that are NULL 90%
of the time.
So, the table in the CR that you mention might be the right place.
I personally wouldn't do it because I think that the whole idea of the Content
Repository is basically flawed (See Lars' posting on the subject about a year
ago or so).
Now, as I am also one of those people (Just as a reminder, I *don't* want to start
that discussion again, 😊 who think that objects like rel_segments are
useless, the optimal solution would be to first remove the useless crap from
acs_objects and then do what Dirk suggested.
Here's what we actually do: We use a separate table called acs_objects_description to
store the information Dirk mentions. So whenever you decide that your object
type needs to be searchable, bookmarkable and generally behave as a piece of
content, you start adding those rows to acs_objects_description. You
then join to acs_objects if you need information that is there.
