Developer vs. DBA role

Question

Developer vs. DBA role

Viewing 6 posts - 16 through 20 (of 20 total)

You must be logged in to reply to this topic. Login to reply

Phil Parkin SSC Guru Points: 245813 More actions · Answer 1

JoshDBGuy (12/10/2014)
Grant Fritchey (12/10/2014)
Small company or not, I strongly recommend putting process for getting stuff out to production into place and following it religiously. The last thing you want are for changes to get made to your production server that don't exist in your dev or test environments. That will lead to even more issues. Even if you give this person access to prod (something I'm against generally), you have to make sure you have that process and that everyone agrees to follow it.
I totally agree but you can expect a lot of resistance. I'm in the middle of this right now.

This is true.

Sometimes, you just need to make sure that you have made your position very clear and very public. If management decide not to heed your advice, that's their choice, not yours.

Then, when something goes badly wrong, you will be an 'I told you so' position of offence, rather than being the target of blame.

If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.

Grant Fritchey SSC Guru Points: 397721 More actions · Answer 2

JoshDBGuy (12/10/2014)
Grant Fritchey (12/10/2014)
Small company or not, I strongly recommend putting process for getting stuff out to production into place and following it religiously. The last thing you want are for changes to get made to your production server that don't exist in your dev or test environments. That will lead to even more issues. Even if you give this person access to prod (something I'm against generally), you have to make sure you have that process and that everyone agrees to follow it.
I totally agree but you can expect a lot of resistance. I'm in the middle of this right now.

Hopefully not to establishing process. I mean, you will see it in some cases. I worked for a company that gave EVERYONE 'sa' privs. But that's a pretty extreme exception.

I'd focus more on the process and less on the access. You have a stronger case to build there. And eventually, one will lead to the other.

----------------------------------------------------The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood... Theodore RooseveltThe Scary DBAAuthor of: SQL Server 2017 Query Performance Tuning, 5th Edition and SQL Server Execution Plans, 3rd EditionProduct Evangelist for Red Gate Software

Chris Wooding SSCarpal Tunnel Points: 4427 More actions · Answer 3

It also depends on the industry your company is in. Some, such as finance, require a clear separation of duties between those who develop software and those who release it to the production environment.

Kris Gruttemeyer Ten Centuries Points: 1185 More actions · Answer 4

I like to think of anyone with sa as someone who could potentially cost me my job. As a DBA, your #1 priority is to protect the company's data. Part of that is controlling access levels of users.

I had to address this when I came on board with my current company and explain that people with that privilege can modify absolutely anything, including, but not limited to, dropping tables, running DELETE statements, as well as modifying all server settings. Once I explained that to my boss, I was in a better position to bargain.

Sometimes, our higher ups need to understand the potential risks in order to make a decision on stuff like this. However, my boss is awesome and trusts what I say. Most may not have that luxury. I'd start by having a conversation with your supervisor about this issue, be kind and gentle and show that you are truly just care about the data and protecting the company's assets. That should at least get you in the door and get the conversation started.

xsevensinzx One Orange Chip Points: 25560 More actions · Answer 5

Yeah, development environment is all he/she needs if they are developing packages or systems via SQL stored procedures.

Last thing you want is dozens of people with rights who are doing diverse roles. Keep it structured, just like your databases. 😉

Nadrek SSC-Insane Points: 20039 More actions · Answer 6

I'd ask why they want it, in terms like "What operations are you trying to do that you can't" and "Please send me a screenshot that includes the error message".

Then figure out what the fine-grained rights required are, and the other things those allow someone to do.

For a development environment, I personally don't mind giving a developer ALTER TRACE, SHOWPLAN, and VIEW SERVER STATE permissions; I'd like them to develop efficient SQL, and running Profiler can help a lot.

If they want securityadmin or dbcreator, then I say no; they don't get to grant other security, and they don't get to create databases (i.e. without setting up index maintenance, backups, choosing the right recovery model, setting size and autogrowth reasonably, doing capacity planning, etc. etc.)