Forum OpenACS Development: Re: cc_users considered harmful (sometimes at least)

Error in include template "/var/www/openacs/packages/openacs-bootstrap3-theme/resources/templates/packages/forums/lib/search/search-form": can't read "form:id": no such variable
Collapse
2: Re: cc_users considered harmful (sometimes at least) (response to 1)
Posted by Janine Ohmer on 08/23/03 03:51 PM
cc_users is very expensive on the acs-admin/users page too, because it does a count(*) of registered users (I think, I'm not looking at the code at the moment) and it takes quite a while once you get past 10,000 or so users.

If it doesn't kill performance too much maybe you could include the minimum needed for that page as well?  Then it truly could be called cc_users_slim, or maybe cc_users_lite.

Collapse
3: Re: cc_users considered harmful (sometimes at least) (response to 2)
Posted by Tilmann Singer on 08/23/03 07:23 PM
Why do we need a view for this at all? Why not encourage people to join against the persons table if they need first_names, last_name, and additionally against parties in case email is needed too? For neither of those attributes the users table is necessary, since the user_id is recorded in the applications table (e.g. the bug assignee), so it is already assured that the party is a user.

Wouldn't that be a little more efficient in most cases, without much overhead (e.g. writing a join against persons is as easy as writing a join against cc_users_lite).

As a side note - usage of person.name in queries that return more than one row should be strongly discouraged for efficiency reasons, right?

Collapse
4: Re: cc_users considered harmful (sometimes at least) (response to 3)
Posted by Dirk Gomez on 08/24/03 10:30 AM
Views are nice for abstracting information - in fact they are the Oracle-recommended way of "information encapsulation". We still very much rely on PL/SQL functions for doing so which usually gives us performance grieving...

The danger with views - evidenced frequently enough in OpenACS - that they retrieve more information than needed in the "master query".

No PL/SQL functions that perform banal operations :)