Question

About best practices on designing stored procedures, should a stored procedure updating a record in a table use the Primary Key to identify the record to be updated, or the Unique Key?

The Unique Key seems like a lot of additional parameters to send in and I can’t think of a situation where the Primary Key wouldn’t be known.

Answer 1

This question bears 2 different aspects.

• The goal: what you want to achieve is to update a given row. Any means allowing you to reach this point is good; in other terms, if the unique key, the primary key or any other combinaison of columns not listed under any unicity constraint would be ok then you might use it.
• The performances: as any other query you really want to go fast and straight to the point. What does it mean? It means that you have to chose the most efficient filter in you where clause. You can measure this by:

1/ the size of the index you are using: choose the smallest one (column size for instance)

2/ the not null attribute of the column of the index you are using: (if your engine allows unique indexes on nullable columns) choose preferably an index that is placed on a NOT nullable column.

3/ the tablespace of the index: you could also see if there is a special storage for an index rather than another, that would improve performances (mounted indexes…)

4/ the column type: usually small numbers are faster to parse than texts (apologize not having sources for that, take it with care)

I can’t think of more now, but I’m pretty sure other people will complete the list.

Cheers.