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: [EMAIL PROTECTED] > Date: 2003/11/19 Wed PM 12:50:12 EST > To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> > 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" <[EMAIL PROTECTED]> > Sent by: [EMAIL PROTECTED] > 11/19/2003 08:55 AM > Please respond to ORACLE-L > > > To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> > 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" > ><[EMAIL PROTECTED]> > >To: Multiple recipients of list ORACLE-L > ><[EMAIL PROTECTED]> > >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 > >* [EMAIL PROTECTED] > > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: Stephane Faroult > INET: [EMAIL PROTECTED] > > 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: [EMAIL PROTECTED] (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). > > > >
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" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED] 11/19/2003 08:55 AM
|
To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> 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"
><[EMAIL PROTECTED]>
>To: Multiple recipients of list ORACLE-L
><[EMAIL PROTECTED]>
>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
>* [EMAIL PROTECTED]
>
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Stephane Faroult
INET: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] (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).
