1

We are thinking of restructuring our database development and deployment processes by using DBGhost, we want to move away from the central development database and bring the database to the source control.
One of the problems we have is a big table with static data (containing translated language strings), it has close to 200K rows.
I know that our best solution is to move these stings into resource files, but until we implement that, will DbGhost be able to maintain all this static data and generate our development and deployment databases in a short time? And if not is there a good alternative to filling up this table whenever we need to?

tom redfern
  • 30,562
  • 14
  • 91
  • 126
pauloya
  • 2,535
  • 3
  • 30
  • 50

4 Answers4

1

This is an older question with an accepted answer, but I have some different input into this.

We use DBGhost and we have lots of static table data, although the largest is only about 20K rows, rather than 200K rows.

DBGhost has a feature to script data (as a series of insert statements). We used that to export our static data into scripts and put those scripts under version control. We tweaked those scripts to clear the data before adding the data back in, so we can use a single script to "reset" the static data for a table. This addition was for our specific needs, and is not the only way that you could handle static data with DBGhost.

The "build from scripts" and "sync" processes both support runnning ad-hoc scripts before and after the process. We added the static data scripts as ad-hoc scripts to run after the build/sync.

DBGhost also supports data synchronization in the synchronization process. The sync process can be configured to do a data synchronization on selected tables. Using this technique, you can have your build process add the data via the scripts, then the sync process can automatically sync the data for those tables. Using this technique, you would not need to change the scripts like we did.

hurcane
  • 1,190
  • 1
  • 8
  • 18
0

Would you be able to take a look at SQL Source Control? We've just added static data support and are looking for feedback prior to the full release.

http://www.red-gate.com/MessageBoard/viewtopic.php?t=12298

Would you be able to explain why you're moving away from a central database development model?

David Atkinson
  • 5,759
  • 2
  • 28
  • 35
  • Hi, thanks for your answer, we already did some tests with Sql Source Control, since we use other products from Redgate this can be a good option for us. I don't think we looked into the static data support, only structure. (Due to technical and management reasons we are still on standby on changing our Central DB development model) – pauloya Dec 13 '10 at 08:16
  • There are 2 main reasons for wanting to move away from central database development model. 1: Isolation - developers getting mad at each other when someone changes a table or some data that breaks the tests the other is working on. 2: Change Management - we can't know who changed what and we can't get the history of changes easily. – pauloya Dec 13 '10 at 08:19
  • @Paulo - SQL Source Control 2 now support static data. It would be great if you could try it again and let us know if it now meets your requirements. – David Atkinson Mar 29 '11 at 21:55
0

DBG is not really designed for moving massive amounts of data

That's from an email received from Innovartis regarding the same question as yours. You've probably found this out by now though!

  • 1
    What version are you running? In V5 there have been some pretty nice performance increases that I have seen first hand. http://www.innovartis.co.uk/v5whatsnew.aspx – Kuberchaun Oct 05 '11 at 15:54
0

Maybe when you asked this they didn't have an evaluation though I'm not sure that is true. The only way you will know is to test it and see how it works.

http://www.innovartis.co.uk/evaluation.aspx

Kuberchaun
  • 29,160
  • 7
  • 51
  • 59