在 SQL Server 中运行 sum 与在代码中处理 sum 都有哪些性能问题? [关闭]
Posted
技术标签:
【中文标题】在 SQL Server 中运行 sum 与在代码中处理 sum 都有哪些性能问题? [关闭]【英文标题】:What performance issues are there with running sum in SQL server vs handling it in the code? [closed]在 SQL Server 中运行 sum 与在代码中处理 sum 有哪些性能问题? [关闭] 【发布时间】:2013-03-04 01:52:40 【问题描述】:我正在做一个项目,因为这是我对 ef 的第一次尝试,我不太确定如何处理某些事情,例如计算我使用 SQL 计算字段来处理行总和(数量 * 价格)和一些计算 Sum() 的 SQL 视图
在过去,我会启动视图或存储过程
更新
我认为被问到的是是否使用混合解决方案来计算 SQL 中的行,或者是否将其转换为代码并在网络服务器上处理?
结果 我继续使用 sql server 选项,但是转向 nosql 我现在知道我应该让它由应用程序的代码处理,因为这将使它更加通用
【问题讨论】:
【参考方案1】:我的经验是数据库在这类事情上的速度非常快,因为它们针对这些操作进行了大量优化。
另外,考虑替代方案。假设您要计算 50,000 行结果集的 SUM(quantity * price)(不管表大小,假设您的查询有 50k 行大)。如果您在您的应用程序中执行此操作,则必须检索 50k 对整数(假设它们是整数,并且是 32 位的 - 它们可能不是)。所以每行 64 位,50k 行,给我们 3.2M 位,或 400KB 的数据。
现在数据库必须通过网络将其发送到您的应用程序,您的应用程序必须等待数据,将其全部读入某种数据结构,然后对其进行迭代。该操作的网络传输时间将抵消您在应用程序中进行计算可能节省的任何费用。
相比之下,如果数据库执行总和,则您必须传输的数据要少得多。如果您能够缓存有关数据库大小的查询(当然这是特定于供应商的),您可能还会获得一些好处。
简而言之 - 除非您有充分的理由在您的应用程序中执行此类操作,否则只需将其留给数据库即可,免去您的麻烦。
【讨论】:
以上是关于在 SQL Server 中运行 sum 与在代码中处理 sum 都有哪些性能问题? [关闭]的主要内容,如果未能解决你的问题,请参考以下文章
在 Visual Studio 代码终端中运行 JavaScript 代码,与在浏览器控制台中运行的相同
SQL Server - 将条件链接到原始行的 SUM 前面的行
SQL Server Reporting Services 在聚合数据上运行总计