>>Hi,
>>
>>I was creating a report based on a table in SQL Server and noticed that it was very slow. I realized that the problem was that the field/column used in selecting the records didn't have an index. I added an index on this field/column and report performs much better.
>>
>>But I also noticed that this table has an identity field but it is not set as Primary Key. How important is it to set an identity column as a Primary Key (which of course will create the index)?
>
>PK should be the key used to estalish relations in joins and/or in seek-equivalent select... from... where pk=other.fk
>Benefit is optimized index scan vs. table scan, also often better than "normal index" scan
>
>Of course automatic check for being candidate is a plus as well, no trigger needed.
>
>PK should be either GUID (+:disconnected clients can easier generate local keys, -:field len) or identity (+:short field len results in faster operations like joins, -:inserting heavy grandparent/parent/children/grandchildren client data always needs key fixup to server generated identity)
>
>You could use belt and suspender approach with GUID as PK for easy insert, triggering indexed identity column (HK as Helper Key) used in joins if set as FK value in related tables: benefit shorter key length.

First, thank you. But in this particular case, for this table, the identity field is not used at all. That is, this table is not related to other tables. And this identity column is of integer type. I suppose there is no harm in making it a PK, which will create an index and probably will update (when new rows are added) faster.