SQL SERVER - INT Vs GUID -wht we should use

Question

I have question that what we should use either Int / GUID in table. Use this scenario.

Use a BIGINT as the primary key – clustered etc, for join's, fast retrievals etc. ie this is optimised for retrieval and user convenience.

The have a GUID as your unique marker for the record, this is what you use when porting data across servers/applications etc. This would never be shown to users, but is stamped to all records.

This gives you the best of both worlds, you avoid the fragmentation and performance hit of using GUIDs as a primary key, but retain its benefit when your moving data/sharing it between systems since you can independently identify the record.

Some may argue that the extra storage cost is excessive, but I'd say spending a few dollars more on your SAN is cheaper in the long run than trying to do two different things with the same data column.

Answer 1

I personally use INT IDENTITY for most of my primary and clustering keys.

You need to keep apart the primary key which is a logical construct - it uniquely identifies your rows, it has to be unique and stable and NOT NULL . A GUID works well for a primary key, too - since it's guaranteed to be unique. A GUID as your primary key is a good choice if you use SQL Server replication, since in that case, you need an uniquely identifying GUID column anyway.

The clustering key in SQL Server is a physical construct is used for the physical ordering of the data, and is a lot more difficult to get right. Typically, the Queen of Indexing on SQL Server, Kimberly Tripp, also requires a good clustering key to be unique, stable, as narrow as possible, and ideally ever-increasing (which a INT IDENTITY is).

See her articles on indexing here:

• GUIDs as PRIMARY KEYs and/or the clustering key
• The Clustered Index Debate Continues...
• Ever-increasing clustering key - the Clustered Index Debate..........again!
• Disk space is cheap - that's not the point!

and also see Jimmy Nilsson's The Cost of GUIDs as Primary Key

A GUID is a really bad choice for a clustering key, since it's wide, totally random, and thus leads to bad index fragmentation and poor performance. Also, the clustering key row(s) is also stored in each and every entry of each and every non-clustered (additional) index, so you really want to keep it small - GUID is 16 byte vs. INT is 4 byte, and with several non-clustered indices and several million rows, this makes a HUGE difference.

In SQL Server, your primary key is by default your clustering key - but it doesn't have to be. You can easily use a GUID as your NON-Clustered primary key, and an INT IDENTITY as your clustering key - it just takes a bit of being aware of it.