April 26, 2006 at 9:46 am
April 26, 2006 at 10:53 am
I just finished putting together a T-SQL standards document for our developers to use. The following sites have some good info to consider:
http://www.sql-server-performance.com/vk_sql_best_practices.asp
http://www.ssw.com.au/ssw/Standards/Rules/RulesToBetterSQLServerDatabases.aspx
http://msdn.microsoft.com/sql/default.aspx?pull=/library/en-us/dnsqlpro04/html/sp04l9.asp
I agree with you with what you've said regarding not being able to review every stored procedure that comes through. If you have developers writing stored procedures, you cannot look at each one and verify that it produces the correct results. This would require you to not only unit-test all t-sql changes that come through, but you would also have to review the specifications for each change as part of the process. The developers should be the ones to unit test their t-sql code and if there is concern with inaccurate results, the t-sql should then be sent to a QA or testing department who would be responsible for verifying that the developers are producing reliable code.
April 26, 2006 at 11:40 am
John's hit my favorite sites, besides this one. There are a ton of articles here on SSC that speak to standards and practices. Here's a few of my favorites:
http://www.sqlservercentral.com/columnists/dhatheway/twobestpractices.asp
http://www.sqlservercentral.com/columnists/nboyle/speed_select.asp
http://www.sqlservercentral.com/columnists/cherring/replacingcursorsandwhileloops.asp
And agreed on the review standards. There's only so much time in a day and only so many resources available. One has to pick one's battles.
April 26, 2006 at 4:47 pm
April 28, 2006 at 11:50 am
These links and hints were very helpful to me. Thanks you!
April 28, 2006 at 2:17 pm
April 28, 2006 at 2:28 pm
I think that has alot to do with the developer's comfort/talent level with SQL. Our programmers have varying degrees of skill with SQL so some need more support than others. We have 2 full time DBAs and around 15 programmers. We (the DBAs) spend the majority of our time optimizing code, writing custom scripts/conversions and upgrades, database change management and other tasks and spend maybe 1/4 of our time supporting programmers.
April 28, 2006 at 2:32 pm
April 28, 2006 at 2:43 pm
We are also in the process of standardizing our processes. We currently do not have all of our database objects in a source/version control software, but we are moving in that direction. We do not have anything formal in place now, but I envision a structure where developers can check out and modify stored procedures and functions, but only DBAs have access to tables (including indexes, triggers, constraints), views and users. We are looking into using DB Ghost now to help with builds (from our source control system) and automated upgrades.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply