Re: Should developers have DBA role?

From: Mark D Powell <Mark.Powell_at_eds.com>
Date: 16 Jul 2003 07:01:18 -0700
Message-ID: <2687bb95.0307160601.1e4232d7_at_posting.google.com>


spam1.minus1_at_comjet.com (larry) wrote in message news:<6669c584.0307151129.34eb5446_at_posting.google.com>...
> Mark.Powell_at_eds.com (Mark D Powell) wrote in message news:<2687bb95.0307140538.6dba1f7c_at_posting.google.com>...
>
> > Our location does not allow developers any create object privileges.
> > All requests for objects are submitted to the DBA even for test
> > systems.
>
> That just isn't possible for us, resource-wise. 20+ developers, dozens
> of production systems, one dba. What is your developer/dba ratio?
>
> If the developers want to compare schemas they can diff the
> > source code and table describes.
>
> We tried that, but the diff output is not very helpful. You'll get
> pages and pages of things that are "different" only because the schema
> name is different, and that one column that has a different size just
> doesn't stand out at all. Do you have any suggested scripts for
> diffing, that can be run by a non-dba? We normally want to diff two
> schemas with different names on the same instance, or two schemas with
> different names on different instances.
>
> The DBA has charge of the production
> > source. The developers check the code out, modify it, and request the
> > DBA to apply the code to production.
> >
>
> What do you use for checkin/out?
>
> > HTH -- Mark D Powell --
>
> It certainly does.
>
> Larry

Larry, The ratio has varied over time from 40 to 1 down to 12 to 1. Most of the time the number is probably in the 15 - 20 to one ratio. We have two Oracle DBA, one of whom (me) is also the backup IMS DBA.

We separate the functions because the developers have enough to worry about: pro*c, plsql, visual basic, Oralce Forms, Oracle Reports, customer requirements that it was felt that they should not have to worry about tablespaces, available free space, table and index parameters, and so on. The DBA will take care of where things go based on a size estimate (initial load and monthly or yearly growth) from the developer.

Also the new laws passed as a result of Enron, WorldCom etc... and which the SEC is working on rules for has numerous provisons that may well require more separation of responsibilites for all financial related systems. The corporate financial process audit requirement applies to how IT handles changes to the system, etc... But those provisions are still in draft phase.

We use SCCS as our source repository. We front-end it with a menu script that runs as its own id. This id is the only id with OS permission access to the code. Developers can check DBA related code, but only the DBA can check it in. The developer modifies the code and submitts a request to the DBA to apply it.

I have no problem with giving developers the ability to create objets in a development environment; however, the larger the shop the more likely the developers will walk on each other's work. You have the issue of one developer hogging space because he or she cannot work with less than half the system worth of data so this works best when space resources are not an issue.

I hope this gives you things to think about. No two shops are exactly the same. How well letting developers do their own thing depends in part on the quality and longevity of the people involved. Separating functions helps maintain order and consistency as the developer turnover increases. Having a 10 man shop where only 2 people are new in 10 years is very different from a shop where 5 out of 10 are new in the last 2 years.

  • Mark D Powell --
Received on Wed Jul 16 2003 - 16:01:18 CEST

Original text of this message