Problem: When displaying all objects categorized in a particular category, I need to list all the object names. I could use acs_object.name, but it's evident that this proc does not scale at all and thus should never used for more than a few objects.
I added another object-type 'named_objects' derived from acs_objects. All displayable objects (i.e. not like acs_rels) should then be derived from named_objects, no longer from acs_objects.
I also added a table acs_named_objects with the columns object_id, object_name and package_id.
Is this the way we want to do this or should we place this information in the acs_objects table (package_id should certainly go there - why not object_name, too?) ? Storing all data in the acs_objects table would have the advantage of not having to join two potentially large tables everytime we want to get the names of some objects.
One disadvantage does this solution have: We could only store an object_name in one language - so this is not multilingual. But I don't see this as a real difficulty since it probably won't happen too often that an object gets entered in more than one language - if it does, it will be package's responsibility to figure out which name to store as the official object_name. And: acs_object.name is unilingual, too. I strongly oppose of adding another column like locale or something similar since that would make queries a lot lot harder and would be a huge scalability threat (unless someone can come up with a real clever way to do it so queries can run fast), which is exactly what should be avoided by introducing named objects in the first place.