Dynamic vs Static Data in source control

A SQL Server Management Studio add-in to source control your database in Subversion or Team Foundation Server.

Moderators: Chris Auckland, David Atkinson, sherr, PhilScrace

Dynamic vs Static Data in source control

Postby robnikkel » Thu Oct 27, 2011 7:21 pm

With our application DB, we have a number of required data rows to run the product, however, the data is dynamic in nature. In other words, it's not "lookup" data that does not change. This data is settings and configuration that can be manipulated via our product.

I don't want changes to this data to be tracked and compared all the time. I would only like this data to be changed manually as required. Anyone know of a way to do this with SQL Source Control? The only solution I can think of is to not static link this data and maintain a separate SQL script to create it.

Thanks,

Rob
robnikkel
 
Posts: 4
Joined: Thu Oct 27, 2011 7:11 pm
Location: Vancouver, BC

Postby andy.campbell.smith » Mon Oct 31, 2011 10:48 am

Hi Rob,

Your proposed solution (static linking the data and maintaining a separate SQL script) is pretty much what we'd recommend, as there isn't a good way to do this with SQL Source Control. Sorry!
Andy Campbell Smith

Red Gate Technical Support Engineer
andy.campbell.smith
 
Posts: 173
Joined: Thu Oct 20, 2011 11:19 am
Location: Red Gate Software

Postby robnikkel » Mon Oct 31, 2011 3:51 pm

Hi Andy,

That's what I suspected. So, we've decided to workaround this issue using static data linking, but it is not ideal. Here's our proposed solution:

Each dev would have two databases linked to our DB in source control. One for developing our software and mucking around with the database. The other for committing schema, and static data changes. We would never commit anything through the first DB, but rather use the "Get Latest" periodically to reset the DB state to what's in source control. The latter would be used to commit schema/data changes as desired and would essentially serve as a master copy of our source-controlled DB.

I think this will work for us, but it's a bit annoying. Hopefully you will have some improvements in the software down the road to manage data a bit better. If you can think of a better workflow, I'm all ears.

Thanks,

Rob
robnikkel
 
Posts: 4
Joined: Thu Oct 27, 2011 7:11 pm
Location: Vancouver, BC


Return to SQL Source Control 2

Who is online

Users browsing this forum: No registered users and 1 guest