Try STUFF string function…

REgards,
NandaKumar

Umesh

As it is being said “Besides, this Primary Key may not be used in Joins.”

It is quite possible that other tables having foreign key referring the primarykey(let it be non Identity column which you have created separately and declared it as pk)

So PK mostly be used as foreign key which can appear in joins also as well as in where clause to filter the records.

so whats the point to create separate column as pk and not to use identity columns as pk?

-Anil

If both indexes, clustered and non-clustered are ordered in the same way then there’s probably no benefit from non-clustered index.

But I’ve heard that in some cases having two indexes ordered in opposite ways will increase performance for select queries.

Also if I use multiple fields in the join/where then I’ll add composite indexes to the table that may overlap with existing ones.

But anyway, always measure your performance after you’ve done changes. For instance, I did some changes to a DB last week and I’m planning to spend part of next week to observe how those changes are affecting the whole software, not just that table.

I don’t think it is a great idea to create a clustered as well as nonclustered indexes on the same column. as the clustered index will be having a reference to all the columns in the table but the nonclustered index will only have a reference to the columns specified.

The key point here is that whenever You update or delete a row (or column)

all the index will be updated.
It is redundant to have two indexes on a column.

In Your case the indexes will take nearly twice time to update, so more time on locks on table.

So a big performance hit.

I have to gracefully disagree and exactly for the points you make against using IDENTITY as PK.

> There is no use of this Primary Key in both application and in T-SQL

That is exactly why I always prefer adding “separate” IDENTITY column as PK. I don’t want to ever show PK values outside the DB. If I need to expose PK outside I make sure in the application code that it is only seen in the data acces layer.

> Besides, this Primary Key may not be used in Joins.

But does it matter? You can use other column in joins and build unique index to those. You just have to make sure you don’t kill performance with additional indexes, of course. If I use PK column in joins or in where-clause, I usually add non-clustered index to it also.

I am not able to get the concept regarding the following point that you have specified:

Please note that many database experts suggest that it is not a good practice to make Identity Column as Primary Key. The reason behind this suggestion is that many times Identity Column that has been assigned as Primary Key does not play any role in database. There is no use of this Primary Key in both application and in T-SQL. Besides, this Primary Key may not be used in Joins. It is a known fact that when there is JOIN on Primary Key or when Primary Key is used in the WHERE condition it usually gives better performance than non primary key columns. This argument is absolutely valid and one must make sure not to use such Identity Column.

Please explain it more clearly regarding the above point.

Thanks,
Santosh

I have one more query relating primary key with performance.

How will performance get affected if I change-

1. Primary key column to some other column which is a candidate key.

2. Content of a primary key. i.e. changing only 1 value in primary key column.

Very good input. Thanks for your note.

Kind Regards,
Pinal

Actually, it can be a good practice. There are plenty of DBA’s who would say “NEVER!!” and others who say “ALWAYS!” to identify columns as the primary key. Reality is that if you have a situation where the values in the primary key can change or if you have a table with sequentially increasing records, then an identity can make an excellent primary key.

Two examples come to mind: First any time you’re dealing with people, the values that might make up the primary key are always mutable. Names not only are not unique but can change, state-issued identity numbers (Social Security in the US or ID cards elsewhere) can change or simply be entered wrong. In this case a separate unique identifier is a good thing.

Second example is a history table. While a timestamp is the first, natural, option for a primary key, it may not be unique depending on the rate at which records are entered. In this case, an identity column as a primary key could be the right answer.

Basically, the real answer is that the right primary key depends on your data and your usage, not on a rule that is simply applied without thinking.

Steve G.

If the app requirements change so drastically that one needs to change the PK, then change the structure of the db. Might as well make a wholesale change at that time, but until then, benefit from the use of logical keys useful for the problem domain instead of creating artificial, synthetic columns as PK.

Most often, I have seen concatenated keys used as a lazy way to enforce uniqueness amongst certain columns. In those situations, I usually demand that a unique key be set up (such as an Identity), and then create Unique Constraints on the columns that need to be unique (a unique constraint in SQL Server can be multi-column).

As to updating keys, I really again try to discourage using any field that may need to be updated as a primary key. You end up having all kinds of relational issues if you have the need to update a key value that has enforced relationships with other tables. You also never know if the business requirements will change, with the result that what used to be a unique primary key now must have multiple records in the table with that value (Product Name or SKU for example). By breaking the key out to a value that is unique and generally unrelated to the item itself in the first place, you can avoid later issues when the requirements of the app change. :)