RE: Development vs. Production DBA

I will ditto Stephane's and Brad's opinions on this.

If the DBA is a competent PL/SQL developer, then sure.

If not, then don't try to write the PL/SQL.

Being a competent PL/SQL developer is *much* more difficult than it was a few years ago.

I can write PL/SQL all day if I can stick with stuff that is 5+ years old.  :)

There are so many new features available to the Oracle developer that it would be very difficult for a DBA to keep up.

Jared

"Stephane Faroult" <sfaroult_at_oriolecorp.com> Sent by: ml-errors_at_fatcity.com
 11/19/2003 08:55 AM
 Please respond to ORACLE-L  

        To:     Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
        cc: 
        Subject:        RE: Development vs. Production DBA

George,

  Early involvement and advice are certainly in my view essential to the success of a project. However, concerning the creation of packages, etc. I fear I don't share your views. Involvement is justified if it adds value. If it's just adding another layer of red tape, forget about it. I think that DBAs should _review_ installation scripts, especially those creating tables, indices, constraints (I sometimes dream of meeting a developer aware of the 'using index' clause), not necessarily to _run_ them but to check that they satisfy local standards; and if they don't, they should be returned to the sender for correction. If you correct scripts and run them, you'll have to do it again and again with each release. We have a duty to teach developers :-).
 Concerning procedures, if you are yourself a competent PL/SQL developer and can review the code and tell people how they can do it better and faster, great. But many competent DBAs are not necessarily competent developers themselves - and I don't think that they have to be. I don't see where having stored procedures created by DBAs on a development database can improve development quality or speed. I see more added value creating a suitable environment (generating a realistic volume of data, creating and administering the suitable roles, creating synonyms to allow people to work on separate parts of a project without having multiple copies of the same database, helping with version control, helping with developing performance monitoring tools, etc.) than running scripts. In many ways, regularly meeting the project manager at the coffe machine may prove more fruitful.

My $ 0.0238 ...

SF

>----- ------- Original Message ------- -----
>From: "Rusnak, George A. (SEC-Lee) CTR"
><george.rusnak_at_deca.mil>
>To: Multiple recipients of list ORACLE-L
><ORACLE-L_at_fatcity.com>
>Sent: Wed, 19 Nov 2003 07:50:21
>
>Group,
>If this was discussed before, I missed it.
>There is a discussion going on trying to define the
>duties of a development
>vs. production DBA and where in-depth DBA
>involvement should occur. Is there
>any papers that anyone can share w/me on this
>subject. IMHO a DBA should be
>involved early on in the project to translate the
>functional requirements
>into a physical model using the features of the
>target version. I also think
>that it should be the DBA's job to create the
>packages, procedures and
>triggers in the development and testing phases. To
>me,this would facilitate
>the transition from testing to production. Our
>development DBA's are
>involved in the production side so are aware of our
>standards.
>Comments, opinions please.
>
>TIA
>
>Al Rusnak
>DBA - WEB Team/CISIS, Computer Operations
>
>* 804-734-8371
>* george.rusnak_at_deca.mil
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Stephane Faroult
  INET: sfaroult_at_oriolecorp.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).



-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: 
  INET: Jared.Still_at_radisys.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).