次の方法で共有

Interesting Rename Refactoring Scenarios: Name Consistency

  • [アーティクル]

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

Comments