Prev: Multiple selects in one
Next: Oracle 10g on Solaris 10 non-global zones with asynchronous I/O
From: Mark D Powell on 11 Mar 2010 10:13
On Mar 11, 12:07 am, "jeffchi...(a)gmail.com" <jeffchi...(a)gmail.com>
wrote:
> So when my developers need to make a change to a procedure, instead of
> just recompiling the procedure they want to create a new procedure
> named like sp_procedure2 and then use the new procedure in their
> application.
> They want to do this so that they don't mess up any other application
> that might be calling the same procedure.  And then when they can get
> around to updating the other applications they will use the new
> procedure.  I was wondering if anybody else does this and what you
> guys think. I am against it but I am getting overruled.  My database
> will look confusing, source safe will be confusing, and now I have to
> maintain multiple procedures when something needs to change.

Jeff, I will join with the other posters who have made several fine
suggestions and suggest you tell your developers that what they want
is not the way code changes should be managed.

You need a combination of source code control and change control
procedures in place that control the process by which code is marked
for update, changed, tested, and promoted. A paper trail showing that
these procedures are followed must be maintained.

You should also have an emergency change procedure documented.

HTH -- Mark D Powell --




From: Mladen Gogala on 11 Mar 2010 11:16
On Thu, 11 Mar 2010 07:13:34 -0800, Mark D Powell wrote:

> Jeff, I will join with the other posters who have made several fine
> suggestions and suggest you tell your developers that what they want is
> not the way code changes should be managed.
>
> You need a combination of source code control and change control
> procedures in place that control the process by which code is marked for
> update, changed, tested, and promoted. A paper trail showing that these
> procedures are followed must be maintained.
>
> You should also have an emergency change procedure documented.
>
> HTH -- Mark D Powell --

There is a sad situation if that is being instituted by the DBA. These
things are usually signed off by the CIO and carved into stone tablets
for later reuse. The commandments should read like this:

Nothing shalt be promoted to the group schema unless it has been
committed to the version system.

Thou shalt put meaningful comments into your code.

Thou shalt not use "select count(*)" to establish existence.

There are many, many more. Modern stone tablets can take much more than
10 commandments.

DBA is not the person with enough authority to introduce the development
process to the company. Management has to do that.



--
http://mgogala.byethost5.com
From: John Hurley on 11 Mar 2010 11:44
On Mar 11, 12:07 am, "jeffchi...(a)gmail.com" <jeffchi...(a)gmail.com>
wrote:

snip

> So when my developers need to make a change to a procedure, instead of
> just recompiling the procedure they want to create a new procedure
> named like sp_procedure2 and then use the new procedure in their
> application.
> They want to do this so that they don't mess up any other application
> that might be calling the same procedure.  And then when they can get
> around to updating the other applications they will use the new
> procedure.  I was wondering if anybody else does this and what you
> guys think. I am against it but I am getting overruled.  My database
> will look confusing, source safe will be confusing, and now I have to
> maintain multiple procedures when something needs to change.

Getting overruled by who exactly?

Is there any kind of change control team in your company?

From: joel garry on 11 Mar 2010 12:17
On Mar 10, 9:07 pm, "jeffchi...(a)gmail.com" <jeffchi...(a)gmail.com>
wrote:
> So when my developers need to make a change to a procedure, instead of
> just recompiling the procedure they want to create a new procedure
> named like sp_procedure2 and then use the new procedure in their
> application.
> They want to do this so that they don't mess up any other application
> that might be calling the same procedure.  And then when they can get
> around to updating the other applications they will use the new
> procedure.  I was wondering if anybody else does this and what you
> guys think. I am against it but I am getting overruled.  My database
> will look confusing, source safe will be confusing, and now I have to
> maintain multiple procedures when something needs to change.

Even Oracle can't get this right. The first two off the top of my
head, statistics generation and job control.

It does make sense for major functionality changes, though Vladimir's
point about overloading is significant for more modern versions of
Oracle, for well-designed systems. (Did I just negate that for the
majority of systems?)

I agree with the chorus for version control. I've been in large and
small shops, and this is the reason for an integration database, in
addition to production and QA and developers own. Even in small shops
with a simple informal system, miscommunication inevitably screws
things up.

The Death part of the System Design Life Cycle is often overlooked. I
also have a lot of code where people didn't want to change procedures
to the new way, so old and new ways are kept, sometimes through
several generations of major ERP upgrades, sometimes with the upgrades
adding the same or conflicting capabilities as older bespoke code.
The real fun begins when they buy a new module that expects the new
code, with expectations it will just plug in because we are at that
version.

jg
--
@home.com is bogus.
Those darn "overpaid, overpriced IT people"!
http://www.signonsandiego.com/news/2010/mar/11/outside-bid-for-city-computer-services-gets-tepid/
From: Mladen Gogala on 11 Mar 2010 13:41
On Thu, 11 Mar 2010 08:44:33 -0800, John Hurley wrote:

> Getting overruled by who exactly?
>
> Is there any kind of change control team in your company?

There probably is a PHB in his company.



--
http://mgogala.byethost5.com
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Multiple selects in one
Next: Oracle 10g on Solaris 10 non-global zones with asynchronous I/O