Do Developers Need Management Studio?
-
A debate has come up in our office regarding installing SQL Server 2005 Management Studio on developer’s PCs. The question is should developer’s have this tool? Let me give you a little background on our development shop. We have been developing in SQL Server 2000 and .NET for a few years now. Developers have Enterprise Manager installed and Query Analyzer. They are use both of these tools and enjoy the benefits of having Enterprise Manager. Now our shop is moving into the SQL Server 2005 world and having Management Studio installed on a developer’s PC has raised concerns among some DBAs.
I would like to hear some pros and cons from seasoned SQL Server 2005 DBAs regarding this issue. And if you are a developer, tell me why you need Management Studio. Also, if anyone has any great references to the pros and cons, please share.
Thank You
-
Hi Lee
Firstly: what are the concerns that you have with SQL MS 2005?
Secondly: If your developers were using isqlw for developing sp's then why not to use SQL MS 2005? They can benefit all new functions and easy-to-use properties of the new GUI.
Cheers
-
Zubeyir,
Thanks for responding. I should say I personally do not have an issue with it. But there are DBAs in our shop that think giving developers MS will give them too much power. I disagree with this because what a developer can do to a SQL Server and its databases is controlled by security and not by the tool itself.
Their claim is developers don't need MS because they can do everything they need to do in Visual Studio 2005. I disagree.
-
Lee,
in short without "sa" developers can make no harm on the productional dbs. Additionally if the DBA's let the developers play with productional dbs then this security "gap" cannot be fixed by forcing the developers to use a "minor" version tool.
SQL MS 2005 is designed for both developer who want to code efficently and for DBA's to make admin actions. Furthermore there are a lot that I can list that you can do pretty easly in SQL MS but can even deal within VS.
Cheers.
-
Thanks again for your response Zubeyir. I agree with your assessment.
-
Lee,
In addition to what Zubeyir said, they won't have any more power than what they currently have with Enterprise manager on their machines. MS just combines the two tools.
The DBAs who are nervous about it could always create their own development tool using SMO. That suggestion may make it seem like MS might not be so bad after all.
John
-
Actually, I agree with letting the developers have Management Studio as well. Since SQL 2005 has a greater granularity level of security, I'd rather they have it than Enterprise Manager. It also has the look and feel of a development application so why deprive them of it? As a DBA my main concern was security--which SQL 2005 does a much better job than EM. I plan to give it to our developers once their systems are upgraded.
-
The access for the developers is controlled by SQL permissions, which the DBAs should have control of unless the developers can use a domain login or sa password to cheat. If the DBAs can't control security, they've already lost the battle. The tools available to the developer don't limit their potential for destruction.
Do the DBAs have any control over what is installed on the developer's computers? Can they keep the developers from using Toad or SQLEdit or some equivalent? Quest and Apex would be happy to let them download trial versions. Can the DBAs keep the developers from opening a Remote Desktop connection to a server where Management Studio is installed? Unless the DBAs also control network administration and are much better at it than the developers, I don't see this working.
A developer can write code to open a connection and execute anything they would run in Management Studio. Build a form with two RichTextBox controls, a TreeView, and some SMO code and a developer could have a mini-Management Studio running in no time (if he's any good). I can't imagine any decent developer whining that they can't do something they want to do to a database because they'd have to write code instead of clicking in a UI.
So we can agree that withholding Management Studio cannot be justified on the basis of protecting the data from developers. It will only cause them inconvenience and foster an adversarial relationship with the DBAs (it sounds like one already exists). What reason is there to give it to them, since they already have a lot of data support in Visual Studio?
Do the developers write any stored procs or ad-hoc SQL? Unless the DBAs write and maintain all the stored procs, the developers should have access to Management Studio to test queries and see execution plans.
The Object Browser functionality in Visual Studio is very useful, but not as good as Management Studio. If you need to work with multiple databases, multiple servers, or switch between development and test databases, Management Studio is much more convenient.
These are not overwhelming reasons for giving Management Studio to the developers, but it would make their lives easier. Not giving it to them will encourage them to waste time on suboptimal work-arounds, and planning their revenge (maybe burying the DBAs in badly-written procedures that the developers don't have the tools to optimize?). Assuming the goal (for the company) is to maximize productivity for both DBAs and developers, which scenario do you think will do a better job?
-
I have to agree with Scott, in my evil developer hat there isn't anything you can do to stop me from using whatever access I have. I can download shareware, trial versions, or write my own software to accomplish my goals. In my DBA hat, my best defense is control of what the evil developers have access to and what they can do with it.
As far as which tools developers should be using, that is moot from a DBA perspective. Let the developers use what tools they are comfortable with and be as productive as they can. There's nothing I can do in an IDE than I can't do from a command line anyway, it just takes longer and doesn't have pretty colors.
Turn this question around, how would the DBAs feel if the developers were telling them what tools they can and cannot use?
-
No difference from the access that they currently have for SQL 2000.
Can't see where the problem lies if they couldn't cause damage in the existing system because all the permissions were in place, how could using a different tool, that only encompasses both tools that were there before, be any different?
Either the systems is locked down or it isn't, in which case any tool will do.
-
i am a developer and i have been using ms since i laid my eyes on it. my dba has no problem with me using it.
the issue to do with access to sql objects etc is controlled by the organisational policy and procedures which help to ensure that i do not have access to that i am not supposed to have.
after all as has been said already ms is just an amalgamation of enteprise manager and qa but only better.
admittedly you can use vs but i am more productive on the sql side when i am using ms
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply