Tips for versioning data?

bdbowmanbdbowman Posts: 4
edited March 15, 2011 4:41PM in SQL Source Control Previous Versions
We are currently evaluating SQL Source Compare 2 for a shared dev environment. We have linked the data for 3 tables ranging in size from about 20,000 records to about 160,000 records. Currently, it takes about 15 minutes for the commit changes tab to refresh, and I was wondering if there are any tips or best practices to look at to speed this up.
· Share on Twitter

Comments

  • David AtkinsonDavid Atkinson Posts: 1,458 Rose Gold 2
    160,000 records is a huge static data table! Can I ask what sort of data this is?

    In our research we generally found that static data tables were a lot smaller than this. If we were wrong, we'll definitely have to review the tool's performance.

    David Atkinson
    Product Manager
    Red Gate Software
    David Atkinson
    Product Manager
    Redgate Software
    · Share on Twitter
  • bdbowmanbdbowman Posts: 4
    It is essentially a list of insurance policy documents broken down by coverage type and state. It is also not strictly static, but it is only updated about once every 2 weeks or so and it would be nice to be able to track the changes and who made the change.
    · Share on Twitter
  • David AtkinsonDavid Atkinson Posts: 1,458 Rose Gold 2
    Thanks for the clarification. Does this mean you're using SQL Source Control to track data changes made in the live production database? Or are you referring to changes made to this data in your development environments?

    David
    David Atkinson
    Product Manager
    Redgate Software
    · Share on Twitter
  • bdbowmanbdbowman Posts: 4
    The changes to the data are made in dev and then promoted to test and eventually live. The process for the data changes in these tables is pretty similar to what we do with our schema changes we are also tracking with SQL Source Control.
    · Share on Twitter
Sign In or Register to comment.