与ASP.NET运行时处理
总的来说，我知道将尽可能多的处理从Server转移到应用程序(在我的例子中是ASP.NET)是一种很好的做法。但是，如果应用程序级别上的处理意味着将30+额外参数传递给Server，怎么办？在这种情况下，是否值得将处理转移到Server？
以下是我所面临的具体困境--哪种程序能提供更好的整体性能？
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或
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我使用的是托管主机，但假设Server和ASP.NET运行时驻留在同一台计算机上是有效的，因此两者之间的数据传输可能非常快/可以忽略不计(或者是这样)。
这30个参数基本上是针对不同项目的totalNumberOfRatings。因此，每当我的web应用程序的用户给出itemN的新评级时，totalNumberOfRatingsItemN就会增加1。在大多数情况下，这个评级会给多个项目(但不一定是全部)，因此不同项目的totalNumberOfRatings并不相同。
回答 4
Stack Overflow用户
发布于 2009-06-23 02:54:11
我会胡思乱想，您已经读过SQL Server不是做数学的合适地方了。我认为SQL非常适合执行一些算术操作和聚合操作，比如SUM。只有在实际的负载场景中测量这两种实现才能确定。
SQL不适合做的事情是多元回归和矩阵反演。
在我看来，将增量器移动到应用层听起来像是一种微优化，不太可能为自己付出代价。实现逻辑以增加任一层中的值，从而使代码可读和可维护。
Stack Overflow用户
发布于 2009-06-23 02:26:32
一般来说，将尽可能多的处理从Server转移到应用程序
是一个很好的实践
谁说的？Server在某些方面很好，而在其他方面则不太好。用你的判断。
你所说的“申请”是指
service
- something
- a应用层
- 企业级服务总线组件
- web
- layer？
f 213
有很多选择..。
至于你的具体问题，增加30个字段似乎很可笑。经过30分钟似乎太过分了。有一些背景..。
Stack Overflow用户
发布于 2009-06-23 02:24:21
在这种情况下，性能有那么重要吗？如果不是这样的话，我个人会追求可读性和可维护性--这意味着按照与系统其他部分相同的标准来实现它。
https://stackoverflow.com/questions/1030339
复制相似问题
腾讯云开发者
