Question

Could you please opine if having identity column as primary key is a good practise? For ORM tools, having identity column on tables helps. But there are other side effects such as accidental duplicate insertion.

Thanks Nayn

Answer 1

IDENTITY keys are a good practice for server-side generated keys, in environments where you don t have replication or heavy data merging. The way they re implemented, they don t allow duplicates in the same table, so don t worry about that. They also have the advantage of minimizing fragmentation in tables that don t have lots of DELETEs.

GUIDs are the usual alternative. They have the advantage that you can create them at the web tier, without requiring a DB round-trip. However, they re larger than IDENTITIES, and they can cause extreme table fragmentation. Since they re (semi) random, inserts are spread through the entire table, rather than being focused in one page at the end.

Answer 2

Yes, using a INT (or BIGINT) IDENTITY is very good practice for SQL Server.

SQL Server uses the primary key as its default clustering key, and the clustering key should always have these properties:

narrow
static
unique
ever-increasing

INT IDENTITY fits the bill perfectly!

For more background info, and especially some info why a GUID as your primary (and thus clustering key) is a bad idea, see Kimberly Tripp s excellent posts:

If you have reasons to use a GUID as primary key (e.g. replication), then by all means make sure to have a INT IDENTITY as your clustering key on those tables!

Marc

Answer 3

I use a Guid because it really helps when I am dealing with distributed applications. Especially when all the distributed instances also need to create new data.

Nevertheless, I don t see any problems with autoincrement integer primary keys in simple situations. I would prefer them actually because it is easier to work directly with SQL queries because it is easier to remember.

友情链接