Don’t pass over synonyms

I am finally back in the writing saddle again with a spree of tidbits for the month of April 2015. These articles will focus on learning a simple TSQL command or technique.

Today, I want to talk about how synonyms can be used to preserve backward compatibility objects while allowing for schema redesign in existing databases.

The CREATE SYNONYM and DROP SYNONYM key words were added to the TSQL language in the 2005 version. The main purpose of the construct is to provide a simple name to reference a database object that is addressed by a two, three or four part notation.

I think this construct has been over looked by developers who’s main job is to maintain older systems.

For instance, lets make believe we have a banking system that has three tables [CUSTOMERS], [ACCOUNTS] and [TRANSACTIONS] that was created before SQL Server 2005. All the tables reside in the [dbo] schema. However, managing objects at a schema level simplifies security. We grant rights to a group of tables, not to a single table.

Now, during a software maintenance project we have the opportunity to move all three tables to a [DAILY] schema. The most important goal of the project is to maintain compatibility with existing code.

How do we accomplish this feat?

Do not fret, the we can use synonyms to main backward compatibility.

The first step is to create a very simple database. Assuming that you have a MSSQL directory on the C: drive with two sub-directories named DATA and LOG, the code below will create the sample database.

The second step is to create the customer table. The snippet below has a typical insert statement that might be coming from our legacy application.

The third step is to create the new schema to hold tables that have common business functionality. This type of grouping allows security to be given out at the schema level instead of the table level.

The fourth step is to move the table to the new schema. A synonym is created to maintain backward compatibility.

Please note, that some TSQL statements are smart enough to not be fooled by synonyms. For example, the TRUNCATE TABLE statement knows that a table name is not being supplied but DELETE statement does not care.

Last but not least, a TSQL developer should test the existence of an object before creating a new one. If the object exists, one solution is to drop the object before creation. Please note that ALTER SYNONYM syntax does not exist!

To recap, I think that the SYNONYMS are a under used feature in the TSQL language.

Another good use of them is to point to reference tables in a [COMMON] database from multiple [BANKING] database shards. This assumes all databases are accessible to each other. Thus, we do not have to duplicate the [ZIPCODE] table to have it accessible to all databases.

While we have only talked about referencing tables in this simple example, SYNONYMS can reference functions, stored procedures and views. Please see the MSDN page for more details.

In the future, I hope you do not pass over the use of SYNONYMS when re-organizing your database schemas.

Related posts

Leave a Comment