Re: why administrator refuse to give permission on PLUSTRACE

From: Peter J. Holzer <hjp-usenet2_at_hjp.at>
Date: Sat, 3 Nov 2007 15:49:04 +0100
Message-ID: <slrnfip2j0.4uc.hjp-usenet2@zeno.hjp.at>

On 2007-11-03 13:23, DA Morgan <damorgan_at_psoug.org> wrote:

> Peter J. Holzer wrote:

>> On 2007-11-03 06:30, DA Morgan <damorgan_at_psoug.org> wrote:

>>> But lets give you an opportunity to test those developers around you to
>>> see how good they really are.
>>>
>>> What would you do if the stored procedure "test" was identified as the
>>> issue?

[...]

>>> CREATE OR REPLACE PROCEDURE test IS
>>> BEGIN
>>>    FOR r IN (SELECT * FROM parent)
>>>    LOOP
>>>      r.part_num := r.part_num * 10;
>>>      INSERT INTO child
>>>      VALUES
>>>      (r.part_num, r.part_name);
>>>    END LOOP;
>>>    COMMIT;
>>> END test;
>>> /

>>
>> I realize of course that your example isn't meant to do anything useful,
>> but that's what makes it unrealistic. Because if I find a procedure
>> called "test" which does what the procedure above does, and which
>> appears to be "the issue", the first questions I am going to ask are:
>> What is this supposed to do? Is it doing that? Is it needed at all? If
>> it is, when is it needed? Why is it not documented? Only after
>> answering these questions and establishing that the procedure is indeed
>> useful and needs to be called as often as it is (which includes
>> documenting it and probably renaming it to something more descriptive)
>> am I going to look into how to make it faster. (At least in an ideal
>> world - if the users are breathing down my neck I might try the obvious
>> optimization first and then do it right).

>
> You are mostly correct in your assumptions. But I am still waiting for
> some hotshot developer, one who thinks he or she is good enough to be
> given DBA privileges in a production database to identify the glaring
> problem in the procedure I created and fix it.

You mean the loop instead of a straight insert ... select? That's the "obvious optimization" I alluded to. Somebody else had already pointed that out. You don't need to be a "hotshot" developer to see that - any developer who doesn't see that on the first glance needs some basic SQL training (and any developer who doesn't measure performance before and after the change needs some basic performance tuning training).

> I am already on record stating that I think DBAs should give developers
> PLUSTRACE in development and test. So I am not trying to stomp on
> developers egos.

The point isn't the developer's (or the DBA's) ego. It is getting the necessary information to the developer.

> My point from the beginning is that developers need the best tools and > the greatest access but NOT in prod.

A developer should not need to access a production database. He probably doesn't even want it. It may sometimes be necessary because a problem cannot be reproduced in testing.

-- 
   _  | Peter J. Holzer    | It took a genius to create [TeX],
|_|_) | Sysadmin WSR       | and it takes a genius to maintain it.
| |   | hjp_at_hjp.at         | That's not engineering, that's art.
__/   | http://www.hjp.at/ |	-- David Kastrup in comp.text.tex

Received on Sat Nov 03 2007 - 09:49:04 CDT