I've run across this attitude by many and have always had some trouble with
it. Can you tell that I'm a long time developer?
Here are my counter points:
- There should be at least 3 instances in a well managed development
environment. Development, Test and Production. The issues that you point
out should be resolved in the test environment, an exact copy of production
(or as near as you can get it), well before new code is moved into
production. I've followed this procedure and never had a problem.
- Development is frequently hindered by over protective DBAs in
environments of no consequence. Way back when (early 90s) I was working on
VAX/VMS development system where the system administrator insisted that
there was no need for granting all the developers access to the system
monitoring tool. He reasoned that the access might bring the system down to
it's knees with the 4 developers running the tool simultaneously. It took
months and countless conversation to get him to see the error in his ways.
That single change resulted in better, more reliable code. It also ended up
saving the company money as development cycles were shortened. Similar
situations occur all the time in my Oracle development efforts.
- In a development environment, where no real data exists, wouldn't it be
nice if the developer could try several approaches that in a production or
test instance would need additional privileges without having to go through
a change control or a proper blessing by a DBA who may (and in many cases
is) unfamiliar with the requested privilege? That process is best gone
through once, after the developer has decided on what he has found to be
viable alternatives and chosen the best course.
- Most seasoned developers will plan on requiring the fewest possible
privileges as securing their applications is as much an issue for the
developer as it is for the DBA. After all, a developer will need to ensure
that the application is protected against all sorts of security threats
ranging from protecting passwords all the way through to preventing SQL
injection attacks.
As you may notice I've gotten into kerfuffle's on this topic before as there
is no clear right choice. An inexperienced developer or DBA could prove
either of our points for us.
An old curmudgeon disagrees. My take is that in development privileges
> granted to the development schemas should only be what is needed as well,
> and moreover that those privileges should be explicitly granted to the
> development schema either directly or through a role as appropriate (how I
> wish PL/SQL understood roles!). If you don't do this the following will
> happen and be resolved in one of two ways.
>
> The production schema will not be granted sufficient rights.
>
> 1. It will be resolved by granting blanket rights (CONNECT, RESOURCE as
> per a lot of Oracle Corp code). or
> 2. It will be resolved by the dba determining appropriate rights (possibly
> iteratively) and granting them in production.
>
> Put another way what I am saying is that if it isn't done right in dev
> then it will either not be done right in production or a different version
> of the app will be being run in production.
>
>
--
Rumpi Gravenstein
--
http://www.freelists.org/webpage/oracle-l
Received on Tue Jun 12 2007 - 14:09:15 CDT
