<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Allowing effective developer access to SQL Server</title>
	<atom:link href="http://www.allenkinsel.com/archive/2010/04/allowing-effective-developer-access-to-sql-server/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.allenkinsel.com/archive/2010/04/allowing-effective-developer-access-to-sql-server/</link>
	<description>SQL Server, PASS, and other data mishaps</description>
	<lastBuildDate>Tue, 07 Feb 2012 17:21:19 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>By: Karen Lopez</title>
		<link>http://www.allenkinsel.com/archive/2010/04/allowing-effective-developer-access-to-sql-server/comment-page-1/#comment-378</link>
		<dc:creator>Karen Lopez</dc:creator>
		<pubDate>Fri, 20 Aug 2010 21:11:52 +0000</pubDate>
		<guid isPermaLink="false">http://www.allenkinsel.com/archive/2010/04/allowing-effective-developer-access-to-sql-server/#comment-378</guid>
		<description>Another approach I use:

Be generous in granting privileges in the DEV database (but still lock down the server environment), but don&#039;t let Devs promote any DDL to the next environment.  Only the DBAs can deliver/apply DDL to the next (usually QA) environment. So if the devs modify their tables/columns without the architect approving/knowing about it, their deployment to QA will fail.

I use tools that automatically compare the Dev database to the modeled database, then report on differences, so I&#039;m not surprised when changes are coming.  

I find this is a nice trade-off - it lets Devs do some what-iffing/testing/research, but also provides a strong incentive for them to still co-ordinate with the people who do the modeling.

The do sometimes still manage to try to sneak things in.  If this dysfunction gets out of hand, then we go back to a locked down dev environment.</description>
		<content:encoded><![CDATA[<p>Another approach I use:</p>
<p>Be generous in granting privileges in the DEV database (but still lock down the server environment), but don&#8217;t let Devs promote any DDL to the next environment.  Only the DBAs can deliver/apply DDL to the next (usually QA) environment. So if the devs modify their tables/columns without the architect approving/knowing about it, their deployment to QA will fail.</p>
<p>I use tools that automatically compare the Dev database to the modeled database, then report on differences, so I&#8217;m not surprised when changes are coming.  </p>
<p>I find this is a nice trade-off &#8211; it lets Devs do some what-iffing/testing/research, but also provides a strong incentive for them to still co-ordinate with the people who do the modeling.</p>
<p>The do sometimes still manage to try to sneak things in.  If this dysfunction gets out of hand, then we go back to a locked down dev environment.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

