June 3, 2008 at 5:31 pm
My company is trying to establish a centralized database that will push and receive data from application databases.
Currently our centralized database is using auto increment for the primary keys. Some of the application databases use auto increment as well. We are a SQL based company with SQL Server 2000 and 2005.
We were thinking of using merge replication. Our concern is the centralized database and application database will auto increment the same primary keys. Therefore, we may use the GUID as the primary key.
Does anyone have any suggestions or best practices? Any known issues with using the GUID as a primary key? Would service broker be helpful here?
June 3, 2008 at 6:23 pm
In this case GUIDs are a better choice. You can use identities, but pick ranges for each system, large ranges, if you do.
June 4, 2008 at 6:55 am
In 2005 use ordered GUID's. They make a huge difference in performance, especially if you have clustered indexes on the GUID. In 2000, you'll have to just deal with the performance slow-down. This is mostly seen in tables that have to refer to the GUID as a foreign key, not the PK values themselves.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
Viewing 3 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply