Re: developer privs in development (old thread inaccessible)

daniel morgan is 100% correct on this one, DBAs need to work with developers and not act like the protectors of the system. Im of the opinion(since I do both dba and development work) that developers should be given free reign on the development system until and unless they prove me wrong.

The first thing that should be done when joining a project is to assess the skill level of senior members of the team. We all know from experience that alot of 'senior' people dont know anything about the database even if they have coded pl/sql for 10 years. If that is the case you have one of two options.

1. take away privileges and hide everything from these guys
2. Attempt to teach them about the database

the second option is in large part on the shoulders of the developers. Do they want to learn? and more importantly do they think they know everything? We have all heard the 'i dont need to know?' or you tell someone something they dont like what you have to say, so they pretend like you never said it in the first place. Been there. Its really bad when its your boss who is like that...

There is no reason why a good developer cannot learn the core functionality and architecture of the database. I usually play it by stating that its good for their career and it is. Makes them more productive and in the long run they will make more money.

Im also of the opinion that there is only so much you can teach someone. To become really good at anything, people have to go get the knowledge themselves. I think 'guided' training is the most effective. I think your role should be to 'de-greekify' the database. Teach them core fundamentals so everything isnt new and the docs quickly become more readable. Dont go 'just read the concepts doc and get back to me'. Open up the docs and say read these 5 chapters to start with and this part of this chapter isnt that important right now. Much more productive that way. Makes everyone's like easier.

It also goes both ways. You help them and they will help you pick up Object Oriented design. So we can all pick up skills. I have been stunned at how much just a small guiding hand from someone who can speak well and understands you cant just give out TONS of information at once can help you speed up the learning process.

On the other hand, if they dont want to learn and insist they know everything and do something stupid. then its

'alter user account lock'

send email an email with the subject, see me.

drak0nian_at_yahoo.com (Paul Drake) wrote in message news:<1ac7c7b3.0312061200.7508f821_at_posting.google.com>...
> Hi Daniel.
>
> I am unable to reply to the thread where your post was 85th.
> I'm including the
>
> ===========================================================
>
>
> > 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.
> >
>
> What Paul Drake and so many others miss is that the security policy of
> a
> company should be a written document. And the security rights and
> priviileges of an application should be part of a written
> specification.
>
> If developers are required to create or modify applications based on
> those two documents then no application they create or modify can
> possibly violate the agreed security policies and specifications.
>
> The only thing the developers could possibly do is make their jobs a
> bit
> easier. Little things like looking up reserved words, checking to make
> sure that all of their dynamic SQL is using bind variables, looking at
> the numbers of hard and soft parses: In short all of the things Tom
> Kyte
> does on his asktom website to demonstrate that things are working as
> they should.
>
> The sad fact is, and since I don't know you Paul I'm not pointing at
> you
> so don't take this personally, the DBAs that are most paranoid about
> giving developers privileges in development environments, are the DBAs
> that know the least about development: The ones that can't actually
> write and debug PL/SQL.
>
> --
> Daniel Morgan
> http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
> http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
> damorgan_at_x.washington.edu
> (replace 'x' with a 'u' to reply)
> ======================================================================
>
> Slashdot posted a topic similar, based upon the following article.
>
> http://www.softwarereality.com/lifecycle/role_fragmentation.jsp
>
> "Somehow over the past 10 years, a cancer has been growing inside
> large organisations - called role fragmentation. As the roles have
> fragmented, an entire non-industry has bloomed. Network
> administration, database administration, security administration,
> component administration, deployment administration, tool
> administration. The list just goes on and on.
>
> This fragmentation has had some seriously negative consequences for
> the industry."
>
> I don't pretend to know everything, I do hope that I know what works
> best for my employer and our clients. I am certainly open to other
> viewpoints that could make the developers more effective, while not
> causing grief due to more rework due to a larger number of issues due
> to permissions differing in dev and test environments.
>
> I did not read that earlier thread from start to finish (85 posts?)
> but will do so now, and would like to pick up that discussion here.
> Again, I'm not able to post on that thread anymore, and saw little
> choice but to start the thread anew.
>
> thanks,
>
> Paul
Received on Wed Dec 10 2003 - 07:14:43 CST