我没觉得用存储过程比直接在程序中写SQL句快呀!大家谈变怎样才能提高访问数据库的速度

解决方案 »

  1.   

    在以前,存储过程相对于动态SQL来说,有速度的好处,但现在数据库系统缓存编译过的SQL,所以速度已经不是一个问题现在主要看重存储过程的是其他2个因素,一个包装问题,即存储过程作为一个procedure,对调用者而言,是输入参数和输出记录而已,至于数据库内部是怎么实现的,调用者不需要知道,另一个安全设置问题,即你可以设置调用者只对存储过程有执行的权限,不需要内部表的权限
      

  2.   

    一楼说的是安全性问题.对于性能方面的问题,我是这样理解的:如果对于经常使用的SQL语句由于每次使用时数据库系统都要进行分析等操作是会影响到性能的,特别是一些复杂的语句,而存储过程编写完成后在第一次运行时,会由数据库系统进行分析编译,下次使用进可直接运行!因而在性能上会有所提高.但对于一般简单的SQL语句,他们之间的性能差异不大!
      

  3.   

    yes, and third:
    If you want to transfer delta by many sql, you can write the login in sp, then you need not send so many delta.
      

  4.   

    不错,速度现在已经不是什么太大的问题了,主要是安全和封装
    在给点详细的:
    使用存储过程封装应用逻辑的优点如下:1、DBA+Developer分工明确。之间代码模块化。减少数据库操作员和程序员的错误。
    2、数据库安全性;可以设置连接字符串中账号只可访问存储过程,不可操作表。这样数据完整性也有保证。
    3、存储过程是编译过的,执行快。
    4、事务的级别,存储过程级别的事务,ADO.net级别的事务比较。一致性。
    5、减少网络通信量。一个需要数行 Transact-SQL 代码的操作由一条执行过程代码的单独语句就可实现,而不需要在网络中发送数行代码。使用存储过程封装应用逻辑的缺点如下:
    1、编程语言SQL功能较差(不包括 SQL 2005)
    2、与编程环境集成不够(不包括 SQL 2005)
    3、移植性差(不同数据库)
    4、数据库服务器压力大
      

  5.   

    如果你的业务逻辑修改了!!就在数据库那儿去修改一下存储过程就是了!!不用改程序!!但是一般的对一个表的Insert,Update,就没有必要用存储过程了!!!
      

  6.   

    一般的对一,两个表的访问都不用存储过程
    这个时候用 O/R Mapping 更方便!!
      

  7.   

    对于速度这一点,我理解应该还是有很大的提高的,特别是对有些使用频繁的SQL语句,因为在存储过程里,如果不是动态SQL语句的话,数据库会进行变量绑定(当然用COMMAND也能实现),可以充分利用数据库的SQL缓存。
      

  8.   

    简单的单表Insert,Update,Delete不赞成用SP
      

  9.   

    尽可能的交给SQL去做,数据库开发和程序开发分开的更明确
      

  10.   

    现在我做一些小网站,基本上都不用存储过程了,起初把数据库设计好,就能够避免很多复杂的sql操作。