Geek Answers Handbook

Recommended approach, how to change the schema of a production SQL database?

Let's say there is a database with 100 + tables and the main function is added, which requires changing 20 existing tables and 30 more added. Changes were made over a long time (6 months) by several developers in the development database. Assume that the changes do not invalidate any existing production data (for example, default values ​​/ nulls are acceptable for added columns, no new relationships or restrictions that cannot be fulfilled) do not exist.

What is the easiest way to post these changes to a schema in a production database? Preferably, without stopping the database for a long time.

+5
source share
4 answers

, "" . , , . (, ), (, , , snot, ) ( , , ). * . , : , , , , , , , . PASS 2009, , , godaddy , .

script .

: , - ? , , ? , , . , 6 . , SSMS VS Server Explored . , T-SQL, , Version Control .

+2

T-SQL script, . ( , ). , . , script .

, : , . . script. . DB .

, , . , , , , . .

+6

diff script . RedGate SQL Compare .

+2

I have been using dbdeploy successfully for a couple of years now. This allows your developers to create small changes to sql that can then be applied to your database. Changes are tracked by a table of changes in the database so that he knows what to apply.

http://dbdeploy.com/

+1
source

More articles:


All Articles