none
三层架构关于数据存储过程? RRS feed

  • 问题

  • 我一直有这样子的一个疑问?为什么要用数据存储过程呢?

    我不用数据存储过程都可以实现,为什么要用呢?

    我也看过了相关的教程.几乎每一篇文章都提到这一点,创建数据存储过程能减轻服务器的负担 .安全性 也比较高.

    我就纳闷了,如果说减轻服务器的负担,那数据库端呢?能减轻吗?

    如果说安全性比较高?那么为什么还要model类呢?

     

    希望各位高手能帮我分析下?


    you are welcome
    2011年1月24日 7:20

答案

  • 其实我已经回答了这个问题,无固定招数。增删改查是基本的操作,对于它们我既会在sql中用,也会在存储过程中用。并不是说修改的时候用,删除的时候不用。不要从基本操作来理解。而要从功能需求的角度来分析。

    怎么用?什么原则?就是能提升性能又不影响扩展性。这句话怎么解释?一、请参照我说的功能需求的变化点和稳定点;二、没有实战或问题背景(功能需求)就不好解释。所以先不要去找列好的标准,第1点是什么,第2点是什么,如果您没碰到这些情况,只会把自己弄的更晕。先练好基本功。

    我只能举个很简单的例子,我会经常使用一些系统的存储过程以提升性能,例如查询sql会使用sp_executesql来执行。例如登入的功能,生成全局的领域标示功能就会用存储过程。

    2011年1月25日 8:01
    版主
  • 着看你是如何开发的,比如有专门的数据库管理员,就写存储过程,你只需要知道调用的存储过程名称,不需要知道具体实现

    如果都是自己写,不太复杂的sql我都直接写在代码,方便维护

     

    看自己的取舍了,各有好处


    http://feiyun0112.cnblogs.com/
    2011年1月25日 2:22
    版主
  • Hi 威尼斯三人,

    欢迎来到MSDN论坛,期待您能在自我提高的同时为社区做出贡献。

    >>
    如果说减轻服务器的负担,那数据库端呢?能减轻吗?
    DAL层写SQL语句的话每一次运行代码都要编译解释,如果应用程序访问数据库相当频繁的话势必会影响效率,写存储过程是会加重数据库端的负担,但这个相对编译代码中的SQL语句的负担来说差距是很大的,总体上来说提高了执行效率。

    >>
    那么为什么还要model类呢?
    举个例子:比如在一段程序执行时有好几次要用到一个用户的所有个人信息,如果没有创建一个用户的model类的话,需要多次访问数据库来获取其信息,而用到model类的话只需要访问一次数据库,用用户的所有信息来实例化一个用户model类的对象,则在此段程序执行结束之前就只需要使用此对象来获取用户信息,而不需要再次访问数据库,占用了更少的资源,速度也很快。

    >>
    都差不多,人的话喜欢用gridview 而又的人喜欢又其他控件.难道这跟程序员决定每一个程序员的习惯吗?
    用不用存储过程视具体情况来定,如果项目很小,或者访问数据库次数并不多,而开发人员又对存储过程不太熟的话当然最好是不用存储过程了。如果项目操作数据库相当频繁的话,当然考虑使用存储过程来提升性能了。

    Sincerely,
    Leo Liu

    Leo Liu [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    2011年1月25日 10:14
    版主

全部回复

  • 您好,

    1、问:存储过程为什么能减轻服务器负担

         答:我想先用一个类比:SQL好比脚本语言,通过解释来运行;存储过程好比编译语言,通过编译来运行。存储过程只在创建时编译一次,而Sql则每次调用都需编译。运行效率高低立判。

    2、问:存储过程安全性

         答:a、可以给存储过程指定特定的用户,只有被指定的用户才能执行

                b、c#在调用存储过程时通常都需要传递参数(类似:@Name),而参数用法是系统防Sql注入的发宝。注:参数用法在SQL中也可使用

    3、问:安全性比较高?那么为什么还要model类呢?

         答:这里的安全性和model没有关系。两者之间无因果关系。model是我们分析客户业务时的产物,例如:客户、商机、订单。

    另,个人经验:虽然存储过程有很多好处,但并不意味着我们需要将sql中的代码,或者是业务逻辑的代码移植到存储过程中。这样会降低扩展性,以及增强和数据库版本的耦合性。我只在查询中使用。

    2011年1月24日 8:05
    版主
  • 刚刚你所说的这句话,给我很大的启示:

    个人经验:虽然存储过程有很多好处,但并不意味着我们需要将sql中的代码,或者是业务逻辑的代码移植到存储过程中。这样会降低扩展性,以及增强和数据库版本的耦合性。我只在查询中使用。

     

    我想进一步的深入理解下,数据的存储过程.什么时候需要建立数据存储过程? 我希望也有很多人在学习C#的过程也遇到这里的问题.他们也想我一样,没有真正的深入理解数据的存储过程.只是通过教程,或者相关的数据看到,有的项目用了数据存储过程,有的又没有用到.

     



    you are welcome
    2011年1月24日 11:13
  • 着看你是如何开发的,比如有专门的数据库管理员,就写存储过程,你只需要知道调用的存储过程名称,不需要知道具体实现

    如果都是自己写,不太复杂的sql我都直接写在代码,方便维护

     

    看自己的取舍了,各有好处


    http://feiyun0112.cnblogs.com/
    2011年1月25日 2:22
    版主
  • 作为一名程序员,在数据存储过程,也不是那么难?关键的是要如何去运用使用它.难道没有一个标准吗?

    每一个程序员,在做项目的时候,都有这样子的一个经验,就例如数据控件来说吧,虽然数据显示的效果

    都差不多,人的话喜欢用gridview 而又的人喜欢又其他控件.

    难道这跟程序员决定每一个程序员的习惯吗?

    有点不可思议?


    you are welcome
    2011年1月25日 6:23
  • 因为没有标准的问题,问题本身千变万化,因此解决方案也是千变万化。我想标准只能根据某类问题域来制定。因此您可以制定符合自己团队的标准。

    举例来说,假如您正在解决的一个问题,只会在一个版本的数据库上使用,逻辑也很简单,将来的变化也很小并可预见,那么为了提高性能,完全可以把逻辑固化到存储过程中。

    可是,如果您要应对的是企业级的应用,需求复杂,逻辑不断变化,那么要是把逻辑固化到存储过程中,那么将来的维护工作将十分艰难。

    为什么要分层,只为在处理复杂问题时能细化不同的职责。一个超简单的登入验证就无需分层。

    给一个个人经验:寻找变化点和稳定点,并想办法把两者清晰的区分开来。在这个过程中寻找标准。

    界面上的控件使用也是同理。

    每个新技术的出现都为了解决其它技术的弱点,要想把这些整理出来是个不小的工作量。您想要存储过程的使用标准,每个用过的人都会给出自己的,微软也会给出建议,但这些不是万能钥匙。它们都会有相应的使用场景。其它技术使用也是一样。如果哪天您能根据不同的使用场景整理出来相应的标准,别忘了分享。

    2011年1月25日 7:13
    版主
  • 你说的这番话是很有道理.

    依你个人的观点,一般数据存储过程用在哪里一个地方呢?

    如查询,修改,删除,或者其他对数据操作的方法等等.


    you are welcome
    2011年1月25日 7:41
  • 其实我已经回答了这个问题,无固定招数。增删改查是基本的操作,对于它们我既会在sql中用,也会在存储过程中用。并不是说修改的时候用,删除的时候不用。不要从基本操作来理解。而要从功能需求的角度来分析。

    怎么用?什么原则?就是能提升性能又不影响扩展性。这句话怎么解释?一、请参照我说的功能需求的变化点和稳定点;二、没有实战或问题背景(功能需求)就不好解释。所以先不要去找列好的标准,第1点是什么,第2点是什么,如果您没碰到这些情况,只会把自己弄的更晕。先练好基本功。

    我只能举个很简单的例子,我会经常使用一些系统的存储过程以提升性能,例如查询sql会使用sp_executesql来执行。例如登入的功能,生成全局的领域标示功能就会用存储过程。

    2011年1月25日 8:01
    版主
  • Hi 威尼斯三人,

    欢迎来到MSDN论坛,期待您能在自我提高的同时为社区做出贡献。

    >>
    如果说减轻服务器的负担,那数据库端呢?能减轻吗?
    DAL层写SQL语句的话每一次运行代码都要编译解释,如果应用程序访问数据库相当频繁的话势必会影响效率,写存储过程是会加重数据库端的负担,但这个相对编译代码中的SQL语句的负担来说差距是很大的,总体上来说提高了执行效率。

    >>
    那么为什么还要model类呢?
    举个例子:比如在一段程序执行时有好几次要用到一个用户的所有个人信息,如果没有创建一个用户的model类的话,需要多次访问数据库来获取其信息,而用到model类的话只需要访问一次数据库,用用户的所有信息来实例化一个用户model类的对象,则在此段程序执行结束之前就只需要使用此对象来获取用户信息,而不需要再次访问数据库,占用了更少的资源,速度也很快。

    >>
    都差不多,人的话喜欢用gridview 而又的人喜欢又其他控件.难道这跟程序员决定每一个程序员的习惯吗?
    用不用存储过程视具体情况来定,如果项目很小,或者访问数据库次数并不多,而开发人员又对存储过程不太熟的话当然最好是不用存储过程了。如果项目操作数据库相当频繁的话,当然考虑使用存储过程来提升性能了。

    Sincerely,
    Leo Liu

    Leo Liu [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    2011年1月25日 10:14
    版主
  • 各位您们辛苦了.虽然我没有真正的做过大项目,但我看的书也看过不少.只是有时候,遇到不懂的问题想弄个明白了.

    真的很感谢你们.


    you are welcome
    2011年1月25日 11:13
  • 十分感谢你了
    you are welcome
    2011年1月25日 11:14