October 21, 2002 at 12:51 pm
Quick question:
Should a DBA or programers upload new SQL objects or make change to SQL objects? This is my first DBA job at a company that has me as the first DBA (I am network admin guy and SQL DBA). I don't know the way other companies handle this issue. My programmers question me that since they can upload ASP files to IIS server, they should do the same to SQL! I can't have a possitive answer to refuse the right to upload for them.
Thx.
October 21, 2002 at 1:01 pm
In our shop the DBA's make all changes to the production objects. We don't let programmers make changes. This allows us to control the production environment. We would hate to have a programmer make changes on the fly. This gives us the necessary checks and balances. Although understand that if you are the only DBA, then you will need to determine who will make changes in your absense. We have at least three DBA's to cover in our shop.
Gregory Larsen, DBA
If you looking for SQL Server Examples check out my website at http://www.geocities.com/sqlserverexamples
Gregory A. Larsen, MVP
October 21, 2002 at 1:39 pm
In all the jobs I've worked, the programmers work with a development enviroment, and have NO rights anywhere else or possibly read rights to stage or test enviroments, but NEVER EVER any rights to production. A change script is generated for each build, which is reviewed by the DBA, and if found to be sound, applied to the next enviroment (this is also the first test for the change script which will be used for the production enviroment). Any failures, or veto by the DBA (along with explanation), requires a new script, which goes through the same process. Quite often, a rewrite to a proc to make it comply with best practices, will knock a build back to development until its resolved. Sometimes, the rewrite is performed by the DBA and sent back to development for functionality verification, and then rolled into the build script to be moved forward. When everything is tested in stage or test enviroment, it is applied to production using the SAME script. No editing of scripts between dev and stage. Editing requires rollback to dev.
The DBA's, in approving a build script run every query, examine the execution plan, examine structure changes, and even syntactical structure of the code itself, along with the basic functionality in order to approve it for the next enviroment. This is the only way a DBA can really be responsible for the database.
When the programmers throw a fit about this (as they do in most places I've seen), tell them that you have written some new subroutines for their software, and would like it implemented immediately...........and then point out the double standard when they respond negatively, (as they will).
If your not gonna help, Please move to the side, because if your not helping the situation, your hurting it....
October 21, 2002 at 2:29 pm
Thank you for your sharing. I am very happy if there is a writen instruction or guideline made from a real DBA focusing on step by step for programmers when they work with SQL. Kind of lazzy to ask but ... I'd like to have something as a foundation.
Thanks.
October 21, 2002 at 2:37 pm
To get a bit of discipline going, goes hand in hand with screaming and kicking from the undisciplined. Once established it is to everyones advantage!
October 21, 2002 at 3:35 pm
We have a system test environment as well which developers have do access to, otherwise it invalidates the environment. All builds are applied here and then once passed applied to production.
Simon Sabin
Co-author of SQL Server 2000 XML Distilled
http://www.amazon.co.uk/exec/obidos/ASIN/1904347088
Simon Sabin
SQL Server MVP
http://sqlblogcasts.com/blogs/simons
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply