Question

I have a situation where I have a database with several tables and large number of records in them , let’s say

Database 1
 - tbl1
 - tbl2
 - tbl3
 - tbln

The tables have PK-FK relationships. The datatype of the PK’s are of type ‘uniqueIdentifier’. Recently I read that having uniqueIdentifier as the datatype can hamper the performance, and it is always better to have integer type for a PK, as it can result it faster indexes.

So we have decided to alter the tables to have the PK datatype as integer Identity. Rest all the structure would remain the same. Also this database have some data in it which should be intact.

Can somebody help me out with the best approach to solve this problem
– After the update, the data and the PK-FK relationships should remain intact.

This is our approach of doing it –

• Create a new table [DB2] with PK datatype as integer Identity
• Add all the PK-FK relationships
• Write a program to migrate the data from DB1 to DB2

We know that this is not a small task because it involves a lot of tables with PK-FK relationships

• Is there a better way of doing this?
• Can we make the alteration/updation on the original database itself without having to create a 2nd Database and then migrate data into it?

Any help appreciated. Thanks.

Answer 1

A GUID can hamper performance but won’t necessarily. I use them all the time, and I use integer-based primary keys as well, depending on the situation.

Unless you can point to a specific performance issue, my advice is to leave well enough alone.

The biggest issue with using uniqueidentifier is how you generate new ID values, especially if the primary key is in the clustered index. If you use NEWID(), it’s fairly random, so it may insert anywhere within the table space, causing unnecessary page splits. Using NEWSEQUENTIALID() is better since it creates sequential uniqueidentifiers, but it has a new random seed each time the database starts, so it doesn’t always append to the end of the table either.

The best solution IMHO is to use a COMB-style GUID that has a portion that is based on the timestamp (which is of course monotonically increasing) and a portion that is random. (As a tiny side-benefit, you can decode the timestamp portion if you ever need to know when the INSERT occurred, assuming the information isn’t stored elsewhere as well.)

Here’s an example COMB function:

CREATE FUNCTION [dbo].NewCOMB(@GUID uniqueidentifier)
RETURNS uniqueidentifier AS BEGIN
   RETURN CAST(
       CAST(NEWID() AS binary(10)) 
       + CAST(GETDATE() AS binary(6)) 
     AS uniqueidentifier)
END;

Here’s a great article on the subject, a little dated but still good:

http://www.informit.com/articles/article.aspx?p=25862&seqNum=7

If you find you must change horses, do it this way:

• Add new ID columns to each table under a different name
• Populate them
• Index them as needed
• Remove the table constraints on the old columns
• Add new constraints for the new columns
• Remove the old columns
• Rename the new columns to the old names (if needed)