Thursday, May 22, 2008

[dotnet] Visual Studio Database Projects in 2005 or 2008

Ah!  You caught me out; yes, we primarily do single-developer projects.

  • Still, I find the Database Project useful not only as a source repository of migration scripts, but also:
  • The list of Database References helps keep the 3 environments handy when wanting to apply a script to any particular environment.
  • And, when you right-click a database object in the Server Explorer and click Generate Create Script to Project = very handy.

From: dotnet@dot.net.nz [mailto:dotnet@dot.net.nz] On Behalf Of Andrew Shearer
Sent: Thursday, 22 May 2008 4:03 p.m.
To: dotnet@dot.net.nz
Subject: [dotnet] RE: visual studio database projects in 2005 or 2008 -->

Do you have a whole team working on this migration script, or just you?

From: dotnet@dot.net.nz [mailto:dotnet@dot.net.nz] On Behalf Of James Hippolite
Sent: Thursday, 22 May 2008 3:51 p.m.
To: dotnet@dot.net.nz
Subject: [dotnet] RE: visual studio database projects in 2005 or 2008

-->

I use Database Projects; here’s how:

  • Each week I create a new migration script e.g. Update20080523.sql.
  • All database changes made to DEV, are scripted and saved to this file.
  • I test and re-test it in DEV.  Obviously this requires some smarts around whether to attempt to recreate objects or update data (IF EXISTS…).
  • I apply it to TEST, usually only once.
  • Finally, during Friday’s change window, I apply it to PROD; definitely only once.
  • It helps to place a comment at the top of the file referencing the changed objects.

From: dotnet@dot.net.nz [mailto:dotnet@dot.net.nz] On Behalf Of Andrew Shearer
Sent: Thursday, 22 May 2008 3:31 p.m.
To: dotnet@dot.net.nz
Subject: [dotnet] visual studio database projects in 2005 or 2008 -->

Who here actually uses these and finds them practical?? Sure, the source control aspect would be great but all i see is this hugely outweighed by trying to manage schema and data changes in a sequential fashion and the major problems that arise if that isn’t done correctly. We don’t roll out the entire database with each product release, but simply the iterative changes that have been made. Is that where we’re going wrong in terms of how a database project works? If you release just the incremental schema and data changes like we do, how are you maintaining this sequence in your database project ‘change scripts’?

thanks

No comments:

Post a Comment