RE: Development vs. Production DBA

I agree with Jared. Take a look at asktom. One will know how much deep is pl/sql. That is what Jared has meant. It is not the features that matter, but how you interpret and mix and match them is what matters. Repeat asktom.

HTH
GovindanK

On Wed, 19 Nov 2003 10:40:10 -0800, ryan_oracle_at_cox.net said:
> there arent that many new pl/sql features. 90% of the time your using the
> generic stuff. the new stuff is nice, but not always that special. Or
> maybe its just because I do it everyday. But how much is new? PL/SQL
> tables? Bulk binds? Dynamic SQL? That stuff is all basic. Its minor
> syntax differences.
>
>
> ive worked with plenty of developers who dont know anything beyond
> cursors. I think everyone should be competetent in PL/SQL. I also think
> all developers should be competent in tuning and architecture.
>
> The skillsets overlap.
> >
> > From: Jared.Still_at_radisys.com
> > Date: 2003/11/19 Wed PM 12:50:12 EST
> > To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
> > Subject: 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
> > >

-- 
http://www.fastmail.fm - Does exactly what it says on the tin
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: GovindanK
  INET: gkatteri_at_fastmail.fm

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).