Forum OpenACS Development: Re: Augmenting acs_objects - adding package_id, name, and clarifying other fields

I guess we are coming down to the question of performance vs. clean design here. I do agree that mapping tables would be the way to go in an ideal world. But they always have the drawback of one additional join. If we make more of them, then we have more joins (e.g. one for package_id and one for subsite_id).

So I think adding certain items to acs_objects and removing them as Jun suggested from CR would make sense. Especially as we so far have not made a decision on whether to strongly encourage usage of CR in every module. It would be bad to add functionality that can be used in categorization and search to CR and not having all modules use the CR.

Why clean design vs. performance? I am seriously asking whether there is a *must* to have a mapping table or not. I am not yet convinced that there is, so it is clean design to add package_id to acs_objects imho.

The fields to be added are useful for every object.

Performance vs. clean design? I thought it came down to what the requirements were, first off and if the fields added really belong to every acs_object.

If it is conceivable that someone would want an object to have zero or more packages or subsites it should be related to, you are stuck with a mapping table. Performance cannot be deteremined until someone lists what they are trying to do, why that is curretly hard to do, and what the new solution would do to make the situation better. You also need to include negative effects.

If you move package_id out of object specific tables, then display inside the application requires an extra join. But it makes it easier for someone to find all objects related to a package. Which is more likely to impact performance? What if you need a one to many relationship?

Many basic objects don't need this, and package_id and subsite_id could never contain a valid value. users, parties, group, rel_segments, acs_rels, etc. Acs_objects needs to contain fields common to _all_ objects, or at the very least only fields which could have valid values for all objects.

Finally maybe some extra fields could be removed from acs_objects: context_id. It hasn't been considered yet, but it might be useful to have more than one context for an object. Also, a lot of applications don't even use this field, so it has a zero or more relationship to other objects. (If you used a tag of 'context', maybe you could use the same object_map table.)