Home/ Questions/Q 258683
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T22:12:03+00:00

I know in general it is a good practice to move as much processing

  • 0

I know in general it is a good practice to move as much processing as possible from Sql Server to the application (in my case ASP.NET). However what if the processing on the application level means passing 30+ extra parameters to the Sql Server. In this case is it worth moving the processing to the Sql Server?

Here’s the specific dilemma I am facing – which procedure will offer better performance overall?

CREATE PROCEDURE MyProc1
  @id int
AS BEGIN
  UPDATE MyTable
  SET somevalue1 = somevalue1 + 1,
      somevalue2 = somevalue2 + 1,
      somevalue3 = somevalue3 + 1,
      ...
      somevalueN = somevalueN + 1
  WHERE id = @id
END

Or

CREATE PROCEDURE MyProc2
  @id int,
  @somevalue1 int,
  @somevalue2 int,
  @somevalue3 int,
  ...
  @somevalueN int
AS BEGIN
  UPDATE MyTable
  SET somevalue1 = @somevalue1,
      somevalue2 = @somevalue2,
      somevalue3 = @somevalue3,
      ...
      somevalueN = @somevalueN
  WHERE id = @id
END

I am using a managed hosting, but I guess it is valid to assume that Sql Server and ASP.NET runtime reside on the same machine, so the transfer of data between the two would probably be pretty fast/negligible(or is it).

The 30 Parameters are basically totalNumberOfRatings for different items. So whenever a user of my web app gives a new rating for itemN then totalNumberOfRatingsItemN is incremented by 1. In most cases the rating will be given to several items (but not necessarily all), so totalNumberOfRatings is not the same for different items.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I’ll make a wild guess that you’ve read that SQL Server is not the appropriate place to do math. I think SQL is quite appropriate for doing a handful of arithmetic operations and aggregate operations, like SUM. Only measuring both implementations in realistic load scenarios can say for sure.

    What SQL isn’t appropriate for are things like multiple regression and matrix inversion.

    Moving incrementors to the application tier sounds to me like a micro-optimization that is unlikely to pay for itself. Implement the logic to increment the values in either tier that makes the code readable and maintainable.

    • 0