机房收费系统——存储过程实践

         在上篇博客中，写了一些关于触发器和存储过程的概念性的内容以及他们之间的区别。今天，通过在机房收费系统中的实践，记录一下存储过程的操作。

         在做结账功能的时候，涉及到了许多表中的操作，比如：统计操作员的售卡张数、充值总数、退卡张数、退还金额等一系列的操作。这时候如果，我们按照常规的思路就是不停的调用数据库，然后从数据库中取出数据后计算数据的条数和某一列的总和。这样的操作，固然没有什么错误，但是，势必会给“程序猿”的我们带来不少的麻烦，工作效率也随之降低。这时候，存储过程就派上用场了。

具体存储过程的建立，就用图来说话吧：

第一步：

 

 

第二步：右击“存储过程”，选择“新建存储过程” 

 

  

第三步：

在指定区域写入存储过程的语句，以下均已结账汇总功能时的存储过程

 

说明：由于以上的查询操作查询出的数据放在一系列的表中，所以，本人通过集合间的“并”操作，实现让所有的数据都放在一张表中。“并”的关键字是“UNION 【ALL】”，如果，上述操作中不带关键字ALL时，返回结果消除了重复元组；而带ALL时，返回结果中未消除重复元组。这样得到的数据放在一个只有一列多行的二维表中。

以上就是关于存储过程操作的内容。在上篇博客中，好像没有说明存储过程的缺点，在此就做个补充，存储过程的缺点如下：
    1.如果更改范围大到需要对输入存储过程的参数进行更改，或者要更改由其返回的数据，则您仍需要更新程序集中的代码以添加参数、更新 GetValue() 调用，等等，这时候估计比较繁琐了。
    2.可移植性差
    由于存储过程将应用程序绑定到 SQLServer，因此使用存储过程封装业务逻辑将限制应用程序的可移植性。如果应用程序的可移植性在您的环境中非常重要，则将业务逻辑封装在不特定于 RDBMS 的中间层中可能是一个更佳的选择。
    3.   大量采用存储过程进行业务逻辑的开发致命的缺点是很多存储过程不支持面向对象的设计，无法采用面向对象的方式将业务逻辑进行封装，从而无法形成通用的可支持复用的业务逻辑框架。

    4.代码可读性差,相当难维护。

 

    以上内容，均为本人实践所得，如有更好的方法，欢迎拍砖！