2

I have been creating database tables using only a primary key of the datatype int and I have always had great performance but need to setup merge replication with updatable subscribers.

The tables use a typical primary key, data type int, and identity increment. Setting up merge replication, I have to add the rowguid to all tables with a newsequentialid() function for the default value. I noticed that the rowguid has indexable on and was wondering if I needed the primary key anymore?

Is it okay to have 2 indexes, the primary key int and the rowguid? What is the best layout for a merge replication table? Do I keep the int id for easy row referencing and just remove the index but keep the primary key? Not sure what route to take, Thanks.

Andriy M
  • 76,112
  • 17
  • 94
  • 154
Phxmobdev Developer
  • 23
  • 1
  • 5

2 Answers2

1

Remember that if you remove the int id column and replace it with a GUID, you may need to rework a good deal of your data and your queries. And do you really want to do queries like: 

select * from orders where customer_id = '2053995D-4EFE-41C0-8A04-00009890024A'

Remember if your ids are exposed to any users (often in the case of a customer because the customer table often has no natural key since names are not unique), they will find the guid daunting for doing research.

There is nothing wrong in an existing system with having both. In a new system, you could plan to not use the ints, but there is a great risk of introducing bugs if you try to remove them in a system already using them.

HLGEM
  • 94,695
  • 15
  • 113
  • 186
  • Thanks so much for the help. I am thinking of starting over because I don't want any future problems so is using only the rowguid and acceptable design? should I set the rowguid as a primary key? and lastly does the column have to be name rowguid for replication or can I just name it user_id? Once again thank you so much for your help. – Phxmobdev Developer Jan 09 '12 at 22:18
0

The only downside of replacing the integer primary key with the guid (that I know of) is that GUIDs are larger, so the btree (index space used) will be larger and if you have foreign keys to this table (which you'd also need to change) a lot more space may end up being used across (potentially) many tables.

Chris Shain
  • 50,833
  • 6
  • 93
  • 125