Changing Table Names

At first glance, changing a table name seems like an innocent and easy operation. A review of Figure 8-3, however, shows that the consequences of such a change are greater than you would think. If, for example, we want to change the name of the table WORK to WORK_VERSION2, several tasks are necessary. The constraint that defines the relationship from WORK to TRANS must be altered, ArtistWorkNetView view must be redefined, and then the TRANS_Check- SalesPrice trigger must be rewritten to use the new name.

Oracle Database and MySQL have an SQL RENAME {Name01} TO {Name02} statement that can be used to rename tables, while SQL Server uses the system stored procedure sp_rename to accomplish the same task. However, while the table name itself is changed, other objects that use that table name, such as triggers and stored procedures, will not be modified! Therefore, these methods of renaming a table are useful only in certain situations. Instead, we will use the following strategy for making table name changes. First, create the new table with all attendant structures and then drop the old one once everything is working with the new table. If the table to be renamed is too large to be copied, other strategies will have to be used, but they are beyond the scope of this discussion.

This strategy has one serious problem, however. WorkID is a surrogate key. When we create the new table, the DBMS will create new values of WorkID in the new table. The new values will not necessarily match the values in the old table, which means values of the foreign key TRANS.WorkID will be wrong. The easiest way to solve this problem is first to create the new version of the WORK table and not define WorkID as a surrogate key. Then, fill the table with the current values of WORK, including the current values of WorkID. Then, change WorkID to a surrogate key.

First, we create the table by submitting an SQL CREATE TABLE WORK_VERSION2 statement to the DBMS. We make WorkID an integer, but not a surrogate key. We also must

Part 3 Database Implementation

give new names to the WORK constraints. The prior constraints still exist, and if new names are not used, the DBMS will issue a duplicate constraint error when processing the CREATE TABLE statements. Examples of new constraint names are:

/* *** EXAMPLE CODE – DO NOT RUN *** */ CONSTRAINT WorkV2PK PRIMARY KEY (WorkID), CONSTRAINT WorkV2AK1 UNIQUE (Title, Copy), CONSTRAINT ArtistV2FK FOREIGN KEY(ArtistID)

REFERENCES ARTIST(ArtistID) ON DELETE NO ACTION ON UPDATE NO ACTION

Next, copy the data into the new table with the following SQL statement:

/* *** EXAMPLE CODE – DO NOT RUN *** */ /* *** SQL-INSERT-CH08-01 *** */ INSERT INTO WORK_VERSION2 (WorkID, Copy, Title, Medium,

Description, ArtistID) SELECT

WorkID, Copy, Title, Medium, Description, ArtistID

FROM

WORK;

At this point, alter the WORK_VERSION2 table to make WorkID a surrogate key. In SQL Server, the easiest way to do that is to open the graphical table designer and redefine WorkID as an IDENTITY column (there is no standard SQL for making this change). Set the Identity Seed property to the original value of 500, and SQL Server will set the next new value of WorkID to be the maximum largest value of WorkID plus one. A different strategy is used for surrogate keys with Oracle Database and MySQL, and these topics will be discussed in Chapters 10A and 10B.

Now all that remains is to define the two triggers. This can be done by copying the text of the old triggers and changing the name WORK to WORK_VERSION2. At this point, test suites should be run against the database to verify that all changes have been made correctly. After that, stored procedures and applications that use WORK can be changed to run against the new table name. 1 If all is correct, then the foreign key constraint TransWorkFK and the WORK table can be dropped with the following:

/* *** EXAMPLE CODE – DO NOT RUN *** */ /* *** SQL-ALTER-TABLE-CH08-01 *** */ ALTER TABLE TRANS DROP CONSTRAINT TransWorkFK; /* *** SQL-DROP-TABLE-CH08-01 *** */ DROP TABLE WORK;

The TransWorkFK constraint then can be added back to TRANS using the new name for the work table:

/* *** EXAMPLE CODE – DO NOT RUN *** */ /* *** SQL-ALTER-TABLE-CH08-02 *** */ ALTER TABLE TRANS ADD CONSTRAINT TransWorkFK FOREIGN KEY(WorkID)

REFERENCES WORK_VERSION2(WorkID) ON UPDATE NO ACTION ON DELETE NO ACTION;

1 The timing is important. The WORK_VERSION2 table was created from WORK. If triggers, stored procedures, and applications continue to run against WORK while the verification of WORK_VERSION2 is underway, then

WORK_VERSION2 will be out-of-date. Some action will need to be taken to bring it up-to-date before switch- ing the stored procedures and applications over to WORK_VERSION2.

Chapter 8 Database Redesign

Clearly, there is more to changing a table name than you would think. You now can see why some organizations do not allow programmers or users to employ the true name of a table. Instead, views are described that serve as table aliases, as explained in Chapter 7. If this were done here, only the views that define the aliases would need to be changed when the source table name is changed.

Changing Table Names