Dynamic vs Static Data in source control
robnikkel
Posts: 6
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
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
Comments
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!
Red Gate Technical Support Engineer
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