Re: Deadly sins againts database performance/scalability

Galen Boyer <galenboyer_at_hotpop.com> wrote in message news:<uu14eyocr.fsf_at_standardandpoors.com>...
> 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.

and for that, you do not require the sys_privs that are granted by default to the dba role created by default in a new database.

you do not need the "ANY" sys_privs to do what you are describing above.
if you have the create sys_privs granted directly or via a role, your can create anything that you can dream of under that app_owner schema.

its only when you reference objects outside of that schema that the "ANY" sys_privs are thought to be required.

Pd Received on Sat Dec 06 2003 - 16:43:57 CST