I agree with what Grant says, but there's an additional point that may apply here. Suppose you don't make the primary ke the identity column, but make it a two column key, with the table definition something like this:

Create table CrmCaseNote

(

ID int identity(1,1),

CRMCaseID int,

Note varchar(200),

constraint pk_CRMCaseNote primary key (CaseID,ID)

)

If you have access through ID, this may need an extra non-clustered index on ID, so maybe isn't useful. But if access through ID is sufficiently infrequent you can do without that extra index.

I've seen a few cases where something like this worked to get performance improvements well after unravelling some unneccessary and pointless use of the the ID column in other tables, as if it were a real key instead of just a visible uniquifier (one of the problems with automatic, unthinking generation of a identity primary key which isn't even a surrogate for any real key is that people will use it in other tables just because it's there).