Sachin Rekhi's Ramblings : Database Refactoring

Interesting Rename Refactoring Scenarios: Coalescing Two or More Objects

SachinRe — Wed, 04 Oct 2006 05:06:00 GMT

Here is another interesting use case for rename refactoring – coalescing two or more objects. What do I mean by that?

Well, this one is slightly different from what would traditionally be considered rename refactoring. It smells more like a semi-automated Merge Tables database refactoring.

Let’s say the scenario here is that you have a [dbo].[Contacts] table and a [dbo].[ContactPhotos] table. Both tables are keyed on ContactID. You may realize that you always end up joining these tables and thus wish to merge the ContactPhotos table with the Contacts table.

Let’s say the table definitions for these objects are as follows:

CREATE TABLE [dbo].[Contacts]

(

ContactID int NOT NULL,

FirstName varchar(100) NOT NULL,

MiddleName varchar(100) NULL,

LastName varchar(100) NOT NULL,

BirthDate datetime NULL,

SSN varchar(50) NOT NULL,

);

CREATE TABLE [dbo].[ContactPhotos]

(

ContactID int NOT NULL,

ContactPhoto image NULL

);

To simplify this task, you can use rename refactoring to get you most of the way. Just follow these steps:

Copy the appropriate column definitions from the [dbo].[ContactPhotos] table to the [dbo].[Contacts] table. In our case, this is simply the [ContactPhoto] column.
Use Rename Refactoring to rename [dbo].[ContactPhotos] to [dbo].[Contacts]. You will be warned that the [dbo].[Contacts] object already exists. Simply say Yes to continue. You will then be shown a list of all the references that will be updated. The beauty of using rename refactoring in this way is that we automatically find all references to [Contact Photos] and update those references to now point to [Contacts].
Delete the now un-needed old [dbo].[ContactPhotos] file from Solution Explorer.
Simplify queries. Clearly many queries will need to be updated to remove joins where they are now unnecessary. You can view the refactoring log file to see a list of all the places that the ContactPhotos table was referenced and review and update them if appropriate.

In upcoming CTP6 you will be able to leverage this feature exactly as described above. So check it out!

Sachin Rekhi

Interesting Rename Refactoring Scenarios: Name Consistency

SachinRe — Wed, 04 Oct 2006 05:04:00 GMT

One of the primary uses of database rename refactoring is driving naming consistency of your schema objects around organizational standards.

Naming Patterns

There are many kinds of object naming standards. You could, for example, have a standard that all primary key column names must be suffixed with ID. Or you may use naming conventions that specify all index names should be prefixed with IX_. This is often the case for FK, CHK, and many other constraints.

Object Name Casing

In addition to actual naming patterns, it is often very useful for readability, consistency, and maintainability to have standards around casing of objects names. The scenario here is that you don’t want to change the actual object name, but simply the casing of the object name. You may not even want to change the object name casing, but simply standardize all references to that object name to use the same casing. The beauty of the rename refactoring facilities inside Team Edition for Database Professionals is that it allows you to do exactly that. You will see in the next CTP6 that you can accomplish this scenario by renaming an object to the same name but with different casing and it will update the object and all its references to use the exact same casing.

Bracket Object Names

Similarly, databases tend to be inconsistent in their use of brackets around schema identifiers. Some organizations ideally would like to have object names always use brackets, for example, in a [MyTable] format. In addition, all references to the object should consistently reference the table according to the convention. Rename refactoring can be used to enforce this.

I hope that gave you an idea of some scenarios where rename refactoring is interesting for enforcing name consistency.

Sachin Rekhi

MSDN Webcast: Gert and Sachin on Database Testing and Refactoring

SachinRe — Wed, 09 Aug 2006 06:28:00 GMT

Gert Drapers, Development Manager, and I did a MSDN webcast yesterday on Database Testing & Refactoring using Team Edition for Database Professionals. This is the third part of a four-part series on Team Edition for Database Professionals. I would encourage you to check it out! You can see me walking through exactly how you can immediately put these features to use in your own environment.

You can find a link to the On Demand webcast here:

MSDN Webcast: Visual Studio 2005 Team Edition for Database Professionals (Part 3 of 4): Database Testing and Refactoring (Level 200)

And you can also find a link to the entire series here:

Visual Studio 2005 Team System: Power in Simplicity

Sachin Rekhi

Best Practice: Deploying Database Rename Refactorings

SachinRe — Wed, 26 Jul 2006 04:02:00 GMT

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

Book Recommendation: Refactoring Databases

SachinRe — Sat, 01 Jul 2006 21:22:00 GMT

I wanted to send kudos over to Scott W. Ambler and Pramodkumar J. Sadalage for recently publishing a great book on the very topic of refactoring databases.

Refactoring Databases: Evolutionary Database Design

http://www.amazon.com/gp/product/0321293533/104-1114081-9071168?v=glance&n=283155

I'm a big fan of this book. You'll even find me saying so in the book's foreword :) Scott and Pramod have put together an authoritative source on refactoring databases much in the same style as Martin Fowler's original refactoring book. The book educates you on exactly what is database refactoring and a process for actually going about it. Most importantly, it provides an in-depth catalog of many different database refactorings, describing in detail exactly how to execute on them. Prior to this book, database refactoring was often just an academic exericse. But I hope now people will start to adopt this technique as a highly productive aspect of their agile database development.

And once again, Team Edition for Database Professionals hopes to help you realize the power of this technique by offering automated tooling around database refactoring.

Sachin Rekhi

What is database refactoring?

SachinRe — Sat, 01 Jul 2006 20:54:00 GMT

Well, I’m glad you asked :) The best way to explain database refactoring is to offer two different perspectives, depending on the background you are coming from. I offer a view on database refactoring both from the perspective of a seasoned application developer and a traditional database professional.

Application Developer View

For most application developers, the concept of refactoring is not new. Most of the mainstream IDEs, including Visual Studio, have built-in support for automated refactoring. A refactoring is often defined as “a small change to your code which improves its design without changing its semantics.” The whole idea around refactoring is to make small incremental improvements to the design of your application in an iterative and agile way. For the more academic sort, you’ve probably read Martin Fowler’s Refactoring book. The kinds of refactorings you are probably used to are rename refactorings, where you rename a symbol name and all of its references, and extract method, where you take a fragment of a method and separate it out into a reusable method of its own.

Database refactoring is merely extending this concept of refactoring from the application code to your database code. Much in the same way, you can imagine a database rename refactoring would rename a database object and all of its references in the database. Similarly, an extract stored procedure refactoring would pull out a SQL fragment from a stored procedure and place it in its own reusable procedure.

Team Edition for Database Professionals is the first tool to try to bring the same refactoring experience that you have always enjoyed for application development to the data world. We have started this effort with initial support for database rename refactoring fully automated inside the toolset.

Database Professional View

The term refactoring likely means nothing to you. However, let me translate. Let’s take for example database rename refactoring. Terms that we found resonated better with DBAs and DB Devs was the idea of “cascading changes”. Let’s say for example you wanted to rename the Customers table. If you were to perform a rename refactoring on the table, you would rename the table and all the references to the table in views, stored procedures, functions, etc. What a database rename refactoring tool does is find all the references and automate the cascading of these changes for you.

To many database professionals, cascading changes as described above is quite a risky endeavor and often simply avoided. The whole hope with such automated tooling is that managing such changes moves from a fear-inspiring task to one which you can do with confidence.

But now I’m sure you can imagine additional database refactorings. For example, a change type refactoring would allow you to change, say, a column's data type, and it would appropriately change all associated object data types (of foreign keys, of variable assignments of the column, etc). In the future I’m sure we’ll see automated support for many other kinds of database refactorings.

I hope that helped to give you a couple of perspectives on just what is database refactoring. In future posts I’ll be sharing exactly how to leverage Team Edition for Database Professionals to perform a rename refactoring and how to do it safely with confidence.

Sachin Rekhi