sp**********@comjet.com (larry) wrote in message news:<66**************************@posting.google. com>...
Ma*********@eds.com (Mark D Powell) wrote in message news:<26**************************@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 --