What we do in our environments is to create a regular user role that
has Select, Insert, Update and Delete privileges on the objects owned
by the application schema (maybe execute on procedures/packages). Then
depending on the environment, we will grant that role to the
developers, or the testers or ... regular users in production. I've
once had to create a second role, since in one of the application we
wanted to allow a class of users comming into the database not using
the application (they were coming in using an odbc link) to only be
allowed to view information - so they only had the Select privilege
issued on every table and view. The developers are granted the
resource privilege, on top of the regular user role in the development
database/environment, so they can create objects (tables and views)
under their own schema, and do regular DMLs under the application
schema. Note that developers do not have accounts to login to the
testing database or production, testers don't have accounts in the
development database ...
This works quite well for us.
Received on Wed Dec 29 2004 - 11:57:17 CST
