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