Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>The best practices for managing the lifecycle of <strong>any</strong> database, regardless of technology, are:</p> <ol> <li>You should be able to build your project in one step. This includes running your unit tests, integration tests, regression tests, and by extension testing your migrations. (This is, of course, point 2 in <a href="http://www.joelonsoftware.com/articles/fog0000000043.html" rel="nofollow noreferrer">The Joel Test</a>.)</li> <li>By extension, you should be able to deploy your database changes in one step.</li> </ol> <p>At the very least, you should get something out of your automated build that you can run, without tweaking, on your production server, to upgrade your database to the new version when you are upgrading your program. Ruby on Rails migrations are a good example of how it should be done.</p> <p>Unfortunately, SQL Server 2005 database projects take a completely different approach, which, as far as I can see, is totally incompatible with these principles. They do offer "incremental deployment," but it seems that this is based entirely on schema comparison tools. Schema comparisons are useful as a starting point, but there are many database refactorings that they can not handle, and more often than not, you are going to have to tweak them (a process made all the harder by the long-winded, difficult to read, spaghetti code that they generate.)</p> <p>I've written a blog post where I <a href="http://jamesmckay.net/2009/06/why-sql-server-2005-database-projects-in-vsts-are-a-bad-idea/" rel="nofollow noreferrer">examine these issues in more detail</a>.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload