| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: RE: Development vs. Production DBA
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
> >
> --
> 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).
>
>
>
>
| "Stephane Faroult" <sfaroult@oriolecorp.com>
Sent by: ml-errors@fatcity.com 11/19/2003 08:55 AM
|
To: Multiple recipients of list ORACLE-L <ORACLE-L@fatcity.com> cc: Subject: RE: Development vs. Production DBA |
-- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: <ryan_oracle_at_cox.net INET: ryan_oracle_at_cox.net 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).Received on Wed Nov 19 2003 - 12:40:10 CST
 |
 |