Nowhere in my response did I say anything at all about asking for permissions etc...
Obviously asking for sysadmin rights just because it makes life easier you should expect to get a short and sharp "NO!"
However it also seems ridiculous to suggest that DBAs are so fragile that you are not even allowed to say "I think you are incorrect because of ...." to them without them blowing their top. To me if they did that they are being an arsehole - telling someone you think they are wrong and giving reasons/stats why should not be met with rage and tantrums it should be met with the mentioned respect and also with communication so that the person understands the reason, i.e. spreading the knowledge, otherwise how is non-DBA ever going to learn.
However on the other hand it sounds like you are saying that DBAs have a license to be complete arseholes and that "collaboration means licking their boots and putting them on a pedestal.
Respect and cooperation cuts both ways.
I am not sure that I agree that was being said. The security, availability and functionality of a companys mission-critical data assets lie in the hands of the DBA. There are too many developers out there that don't understand the architectural niceties of a RDBMS, only the code that can extract data. The DBA is there to protect that data. Would you call the guard that won't let you into a building because you are not authorised an (in your own words) arsehole. I think not and data protection should maintain the same philosophy.
There are DBAs out there that are truly difficult to work with. Same can be said for developers. Or storekeepers, bus drivers, road sweepers etc....
The point is simple: A mutual respect for the skills and requirements of each party in the argument is the only way a dispute can get resolved. If you start a discussion agressively, don't expect constructive results. Licking boots is not what is required, simply proof that your request is feasible, safe and in the companys best interests. If it isn't, it won't get implemented.
Well said...in fact, so good, I've quoted it verbatim again...
Would love to witness what a Sys Admin would say if you ask for Domain Admin rights, for the only reason that it would make your job easier and not because there was a genuine necesity for it, and I'm sure the air would turn blue. Now, is the Sys Admin an arsehole?
Same for the Security Admin, when you ask to open up loads of ports on ther Firewall, because it makes your life easier. Is s/he being an arsehole when they politely tell you where you can shove yourself?
I've been on both sides of the fence, as a Developer, Developer DBA, and Production DBA, and I've witnessed the horror of having to in-fill following a data breach, trying to retrospectively implement better security on 'live' code - and management had been warned of the serious potential risks, but the DBAs were dismissed as naysayers. It's not fun and it's not pretty...for anyone...DBAs, Sys Admins, Developers, and most important, the business which suffered massive financial penalties due to loss of reputation, loss of customers, regulatory penalties, etc.
Security is not just the domain of Sys Admins, Security Admins, Production DBAs, it's the responsibility of *all*. Just look at the recent breaches in well-known Banks in London, UK, who fell for a bit of social engineering, letting in supposed authorised company IT engineers who then went on to fit hacking components to the bank's computer systems.
Wow.....that was the sort of agressiveness I was alking about! If you have DBAs that react in that way then I would recommend they get help for begin colleric....
I am also well-aware that you did not mention permissions in your answer. I used it as an example of demonstrated bad practice from the side of developers to make their lives easier without concern for company or DB best practices.
I am one of the DBAs that will quite happily admit when I am wrong. But I need to have it explained why I am wrong.
I normally ask one question: Why is my answer or solution wrong? Typical answers from Developers I have closed the door on include:
1. It just is
2. Noone does it like that
3. When I was on my course
4. I read in a book somewhere
and so on and so forth
Am I also wrong to insist that developers produce an application that fits into OUR security model? Our model does not, and will not devolve to mete the sub-standards of a badly or lazily written application.
Let me explain my practice, in the workplace to ensure the safety and security of my Oracle DBs:
1. Developer comes to me and says they need code inderted into production.
2. The code (and its UNDO partner) are run on a test server to esure both function as expected.
3. If the change works but the undo doesn't, the code goes back to the developer explaining it doesn't work. If the change, in an unforeseen circumstance, can't be wound back, it won't be run in production.
4. Once these tests have been successfully completed they will be performance tested. If IO or CPU performance regresses, the code will be rejected. If network traffic increases disproportionately, the code will be rejected. If the code requires elevated privileges due to lazy or bad programming techniques, the code will be rejected.
5. Once I am happy that I can take responsibility for the code it will be run into the production database and checked over the course of its next few runs. If it fails to meet the criteria met in testing, i will be removed and rewritten.
My employers demand the best DBA efforts I can offer them and in order to do that, I require the same from the people whose code I am trusted with. If they can't accept that then the problem is theirs and not mine.
High standards (not necessarily perfectionism) are the key to a successful RDBMS implementation and I will not sacrifice those standards for bad practice.