views:

53

answers:

2

We work with a small development team and a system engineer who deploys the software at certain times.

At the moment we don't have any leading document for database changes. Changes are done in the staging database and added manually to production when the system engineer deploys a new release.

We started to work with DBDesigner Fork to create the design and generate the SQL create script, but we are still not happy with this solution. The solution is incomplete, because it's impossible to create views and stored procedures in DBDesigner Fork for example.

We would like to find a practice/tool to design the database, stored procedures, views, etc. and version the changes in Subversion.

When a new software release is created (tagged in SVN), we should be able to create a patch file for the database (a SQL script for example).

What is the best way to handle the issues described above?

+4  A: 

We are a $2.5B solar manufacturing company that is using Visual Studio Database Edition for all our database management and versioning needs. It has been a very good tool for us. It version controls our databases with TFS integration, does schema and data compares (like Red-Gate), database validations and much more. We couldn't live without it now.

Randy Minder
+1 for VS Database - even if it might not be the best tool out there, i found that it does most of the things that i need like versioning, integration with TFS, deployment to dev / test db's etc. It allows you to treat your DB just like code which is the way i like it. And it being IN VS is just icing on the cake
InSane
@In Sane - Absolutely agree. We also treat our database artifacts just like source code (which they really are). VSDE handles this very nicely.
Randy Minder
Okay, VS Database seems nice. The database design should be leading. The situation on the database server should not be leading. Is this the case in VS Database or are the changes synchronized to the database server?
Bamieater
@Bamieater - The database schema as contained in VSDE should always be considered "the source of truth", not a physical database sitting somewhere. And, yes, VSDE allows you to synch changes to a physical database and allows you to synch a physical database back to the project (very nice).
Randy Minder
+2  A: 

We use source control for versioning. All databases changes must only be made in scripts and placed in source control as part of the branch of the code that goes to production with the rest of the code changes for that version. Since devs don't have any rights to create or alter objects in Prod, this works out well for us as your changes don't get moved up unless they are in a script.

HLGEM