Re: Deadly sins againts database performance/scalability

On 5 Dec 2003, drak0nian_at_yahoo.com wrote:

> the problem with granting an app_owner schema the role DBA is
> that then the application is coded depending upon the DBA role
> (and usually, all of the sys_privs that are in that role, that
> the account invariably grants itself directly). it is such a
> PITA to get changes made to remove queries that hit the dba_
> views (such as dba_cons_columns for RI errors). If the
> developers can't code against the dba_% views, but are limited
> to the all_ views, you don't have as many issues when the code
> runs on a qa db where the app owner account does not have the
> DBA role granted to it.

You are missing my point. I never want the user that the application will log in as to have anything but the priviledges that will be granted to it in public. What I want is a user that has dba priviledges (or a form thereof) that can be used by me and the development crew for the sole purpose of modifying the database for developing the app. I, most definitely, want to hamper the application schema exactly as I plan to in production.

-- 
Galen Boyer