1

Looking at this post:

[What are the best practices for using a GUID as a primary key, specifically regarding performance?

I understand that if I want to use a GUID as the primary key then this should be non-clustered pk and then also create a clustered int unique index (autoinc).

I just want to confirm that with the setup above all joins would still work as usual ie. tables relate on the GUID primary key field? Also, it would appear that the int unique index field would have no relevance in my application and I would just ignore this completely in any queries/inserts/updates?

Community
  • 1
  • 1
A_L
  • 920
  • 1
  • 9
  • 20

1 Answers1

2

There is no point in creating a clustered index on a monotonically increasing numeric field in your table unless you're planning on using that field to access the data.

I suggest you read this post on DBA.SE for a good discussion of clustered and non-clustered primary keys.

Community
  • 1
  • 1
Joel Brown
  • 13,177
  • 4
  • 44
  • 58
  • I suspected that may be the case. I don't have a choice, since my pk is a guid that MUST be non-clustered, fine. If I leave out the int unique index field though that means the table will have no clustered index and apparently every table should have a clustered index: https://msdn.microsoft.com/en-us/library/ms186342(v=sql.105).aspx – A_L Feb 06 '15 at 09:50
  • 1
    @A_L - Every table probably should have a clustered index, but not if you're not going to use it for anything. The main point of a clustered index is access efficiency. If you don't use the clustered index for access (ever) then there really isn't much point in having it. – Joel Brown Feb 06 '15 at 11:27