Forum OpenACS Q&A: Re: Augmenting acs_objects - Add package_id, name, overview, etc. to it

Collapse
23: Re: Augmenting acs_objects - Add package_id, name, overview, etc. to it (response to 1)
Posted by Dirk Gomez on 01/28/03 11:19 PM
Tom, but I just proved that acs_object.name doesn't scale!

As to changing data: if you expect heavy updating/deleting/inserting then you can mumble around with PCTFREE and PCTUSED. Given that the name field is usually quite small there should row migration should almost never happen.

Updating/inserting/deleting into a second table certainly cost, but accesses happen far more frequently.

Following up Branimir's comment: I always found that we had way too many useless joins between acs_objects and acs_objects_description. And I don't mind NULLed columns, they don't take space and don't cost when being accessed.

So here's a step-by-step approach: introduce acs_objects_description with above mentioned fields and deprecate the name and get_url function. If things work out well, then go one step further and try to deprecate acs_objects_description or at least move around some fields (modifying_ip in acs_objects for example looks really useless).

Collapse
24: Re: Augmenting acs_objects - Add package_id, name, overview, etc. to it (response to 23)
Posted by Dan Wickstrom on 01/28/03 11:29 PM
Adding an acs_objects_description table is just and ad-hoc way to store meta-data about content, so If you have objects that need name and url descriptions, why not just store them in the CR and be done with it?  What you seem to be proposing is to build an under-featured CR out of the acs_objects table.  So now we'll have a CR that many people think is too compicated and over-featured, and to fix this problem, we will instead add CR like features to acs_objects and create a parallel lightweight CR repository in acs_objects.

It seems that it would be better to address shortcomings in the CR, rather than create shortcomings in acs_objects.