Welcome to MSDN Blogs Sign in | Join | Help

Best Practice: Deploying Database Rename Refactorings

Team Edition for Database Professionals is targeted primarily at managing iterative changes for preproduction database development.

 

The primary use case for deploying rename refactorings is to your local sandbox server. The cleanest way to setup this sandbox server is to always drop and re-create the database at each deployment. Data can be regenerated for testing purposes using the data generation tool.

 

Sometimes, however, you will want to update an existing database and the data must be maintained. Team Data’s deployment feature does not automatically generate a build script to perform the associated data motion for you. However, this task can be accomplished through the following suggested process. The default build options result in the build script containing an add of the new table or column whenever you do a rename refactor. The default build script does not drop the old table or column. This provides you the opportunity to follow the following process to manually perform data motion using Team Edition for Database Professionals:

 

1.      Perform a rename refactoring operation

a.      Right-click on the object name in Schema View and select Refactor -> Rename…

2.      Build the database project

a.      Right-click on the database project and select Build

3.      Deploy the database project

a.      Right-click on the database project and select Deploy

4.      Perform data motion of data from old table\column to new table\column

a.      Table: INSERT INTO <new_table> (columns) SELECT (columns) FROM <old_table>

b.      Column: UPDATE <table> SET <new_column> = <old_column> FROM <table> WHERE <pk_column> = <pk_column>

5.      Drop the old table\column

a.      Table: DROP TABLE <old_table>

b.      Column: ALTER TABLE <table> DROP COLUMN <old_column>

 

Alternatively, you can avoid performing the data motion manually by finding all adds of the new table\column in the build script and converting them into sp_rename calls. The process for this would look like the following:

 

1.      Perform a rename refactoring operation

a.      Right-click on the object name in Schema View and select Refactor -> Rename…

2.      Build the database project

a.      Right-click on the database project and select Build

3.      Modify the build script to replace add table\columns with sp_rename calls

a.      Table: sp_rename ‘<old_table>’, ‘<new_table>’, ‘OBJECT’

b.      Column: sp_rename ‘<table>.<old_column>’, ‘<new_column>’, ‘COLUMN’

4.      Execute the build script

 

 

Let me know your thoughts on this guidance. Do you prefer one approach to the other? Would you do it another way?

 

Sachin Rekhi

Published Wednesday, July 26, 2006 2:02 AM by SachinRe

Comments

# re: Best Practice: Deploying Database Rename Refactorings

My vote would be for Data Dude to support the rename scenario automatically based on the build target for your DB.  I am not sure the ratio, but my guess would be a majority of people cannot blow away their DB in each deployment.  So if you want to rename a column most of the time you will have to do one of the two options you described above - seems to make sense for the tool to handle the major case.
Not having used Data Dude much yet I can't comment on how it works for me yet - when I get to it I will try and check this out and give more feedback.
Thursday, July 27, 2006 6:04 PM by HintonBR

# re: Best Practice: Deploying Database Rename Refactorings

I think the solutions provided are fine however I think automatic support for this scenario would be great! Perhaps there is an architectural problem in doing this though. As no meta data is stored (from what I can see) with the offline files for change tracking ? E.G. As the offline .sql files only store the latest version of the create statements, it means when the schema compare is done the tool has no way of knowing that the 'FirstName' column for example is now called 'FName' the tool can only see that the create statement calls for a new column called FName and the FirstName column is no longer in the script ? And so accordingly the build script reflects this. Perhaps the solution would be to store meta data with the off line .sql files to track refactoring activity, thus allowing the option of 'do you want to rename' or not. Although this could become pretty complicated when multiple parties perform multiple refactoring operations. Thoughts ?

Saturday, October 21, 2006 10:33 AM by PiersM

# re: Best Practice: Deploying Database Rename Refactorings

I just started evaluation DB Pro. The build/deployment features were very alluring. However, I was disappointed to find that when I renamed a table, the deployment script didn't know what to do. Especially, after the fact that the tool "knew" how to update triggers, functions, and stored procedures (this is nice). This is very annoying and dangerous. I’m not if there is a tool out there that can handle this case automatically. But if there is, DB Pro should definitely have this feature. I think otherwise, the tool deployment scripts are only useful for creating blank databases, and they should have at least a warning saying that the renaming of a table would result in the creation of a new empty table and leaving the old one as it was.

Thursday, October 11, 2007 4:44 PM by Frank C.
Anonymous comments are disabled
 
Page view tracker