SQL存储过程与许多连接VS许多数据库调用到简单的存储过程

时间:2011-12-09 20:33:07

标签: sql-server stored-procedures

我对数据库性能有一般性问题。我正在使用DotNetNuke业务逻辑来创建业务对象和SQL 2008 R2。这是一个Web应用程序(asp.net/c#)。

请考虑以下事项:

我需要加载一个包含很多信息的userprofile,比如姓名,姓氏,XP,硬币,赢了,丢失​​等等。来自10个不同表格的字段很多。

我创建了一个包含许多连接(以及嵌套的select / count语句)的大存储过程,以便在一次数据库调用中获取所有这些信息。

我的问题是,这是正确的方法吗?或者,对简单的存储过程进行许多小型数据库调用是否更好/更高效?

我的想法是,最好进行一次数据库调用,特别是如果你开始拥有数十万用户。但是连接开始变得复杂,并且开始花费一些时间来加载配置文件。

有什么想法?还是想法?

2 个答案:

答案 0 :(得分:2)

我会说,一般来说,单个存储过程将导致比多个存储过程更快的页面加载时间。对于在简单Web应用程序中使用的大多数存储过程,查询执行时间远小于连线时间。换句话说,根据我的经验,只是进入数据库并返回到Web服务器的行为比执行查询需要更多的时间。

但是,这里有几点需要考虑。

  1. 您是否需要为每个查询执行加入每个表?或者,根据其他表中是否存在数据,是否只需要一些连接?如果某些连接是可选的,您可能需要考虑将它们推送到仅在需要时调用的单独存储过程。

  2. 虽然单个存储过程可能更快,但过程的复杂性也可能导致维护系统更加困难。这种复杂性也可能从数据库层溢出到应用层。考虑尝试从数据结果集填充Order对象。如果要优化查询时间,可以想象从不同的存储过程中以不同的方式提取填充订单对象所需的数据。这可能会严重地使对象创建复杂化。性能的提升是否值得维护?

  3. 如果您有其他问题,最好运行SQL配置文件。您可以比较和对比单个复杂过程的CPU和IO,而不是调用几个较小的过程。

答案 1 :(得分:1)

如果你真的需要同时获取所有数据,我会选择SP。如果它很慢,你可以调整它。

如果你大部分时间只需要一点点数据,有些只是现在然后我会选择不那么复杂的SP,但更多的是SP,但只在需要时调用。

相关问题