当前位置:首页 » 服务存储 » 存储过程支持重跑
扩展阅读
webinf下怎么引入js 2023-08-31 21:54:13
堡垒机怎么打开web 2023-08-31 21:54:11

存储过程支持重跑

发布时间: 2023-03-02 14:30:48

Ⅰ 创建存储过程sql语句

1)过程名
存储过程的名称,默认在当前数据库中创建。若需要在特定数据库中创建存储过程,则要在名称前面加上数据库的名称,即db_name.sp_name。
需要注意的是,名称应当尽量避免选取与MySQL内置函数相同的名称,否则会发生错误。
2)过程参数
存储过程的参数列表。其中,<参数名>为参数名,<类型>为参数的类型(可以是任何有效的MySQL数据类型)。当有多个参数时,参数列表中彼此间用逗号分隔。存储过程可以没有参数(此时存储过程的名称后仍需加上一对括号),也可以有1个或多个参数。
MySQL存储过程支持三种类型的参数,即输入参数、输出参数和输入/输出参数,分别用IN、OUT和INOUT三个关键字标识。其中,输入参数可以传递给一个存储过程,输出参数用于存储过程需要返回一个操作结果的情形,而输入/输出参数既可以充当输入参数也可以充当输出参数。

Ⅱ 存储过程是多用还是少用

做项目的时候我们有时候会面临一个选择,我们到底是应该多写存储过程还是少写存储过程了?这个问题的争论也是由来已久,在不同的公司以及不同的技术负责人那里往往会得到不同的答案。在实际项目中我们最后所采取的方式,往往不外乎以下三种方式。
第一种方式是要求所有数据库操作不使用任何的存储过程,所有操作都采用标准sql语句来完成,即便是一个动作需要完成多步数据库操作,也不使用任何存储过程,而是在程序代码中采用事务的方式来完成;第二种方式就是就要求所有的数据库操作都用存储过程封装起来,哪怕是一个最简单的insert 操作。在程序代码看不到一行 sql语句,如果采用分工合作的方式,程序员甚至都可以不懂sql语法。第三种方式是一般相对简单的数据库操作采用标准sql语句来完成,一些相对比较复杂的商务逻辑用存储过程来完成。
当然系统如果采用了hibernate或nhibernate之类的框架,不需要写sql语句的时候,我想还是应该属于第三种方式,因为在开发的时候hibernate框架允许我们在适当的时候,抛开其框架自己写存储过程和sql语句来完成数据库操作。其实这三种方式都各有所长,也各有不足。
第一种方式是所有的数据库操作都采用标准sql语句来完成的方式,在程序的执行效率上是肯定不如后面两种方式,系统如果是一个大型的ERP,这种方式就是绝对不可取的。因为在开发基本结束后,系统如果需要优化或者希望得到优化时,那对开发人员来说就是一件非常麻烦的事情了,因为优化的重点基本上都是集中数据库操作上,开发人员所能做的就是一个个sql语句去检查,是不是还能进一步优化,尤其是一些相对比较复杂的查询语句是我们所检查的重点。分页显示就是一个典型的存储过程提高程序效率的例子。如果使用存储过程来进行分页操作,就是利用存储过程从系统中提取我们所需要的记录集,分页的效率就大大提高了。反过来如果我们不用存储过程进行分页操作,是利用sql语句的方式把所有记录集都读入内存中,然后再从内存中获取我们所需要的记录集合,这样分页效率自然就降低了。当然利用sql语句也能得到我们所需要的记录,而不是所有记录,但是那样麻烦多了,不在我们讨论范围之内。
这种方式另外还有一个不足之处,一个系统或一个项目总会或多或少地存在有一些容易变化而又复杂的商务逻辑,如果把这些复杂的商务逻辑封装到存储过程中,商务逻辑的变化都只涉及存储过程变化,而与程序代码不发生关系,那么不用存储过程太可惜了。
这种方式虽然有不足,但是一旦采用这种方式的话,我们如果对该项目进行数据库移植的时候,开发人员就会觉得当时的决策人是多么的伟大与英明。而且我们知道access和mysql的以前版本是不提供存储过程支持的,所有一些中小项目在这个方面的选择往往也是不得已而为之。不用存储过程有一个优点,调试代码的时候没有存储过程可是要方便很多很多的哦,所以在很多很多的项目中都是采用标准的sql语句而不使用任何的存储过程。这可是大多程序员用标准sql而不用存储过程的直接原因,说白了,就是嫌麻烦。
第二种方式是所有的数据库操作全部采用存储过程封装的方式,如果采用这种方式,程序的执行效率相对要高,尤其面对在一些复杂的商务逻辑时候,不仅在效率方面有明显的提高,而且当商务逻辑发生变化时,我们开发人员做相应的修改的时候,往往都不用修改程序代码,仅仅修改存储过程就能满足系统变化了。
还有一个好处就是当我们开发好的一个系统后,如果发现一种模式或语言在某些方面难以满足需求时,我们就可以很快的用两外一种语言来重新开发,那个时候就非常方便了。比如在02年中科院下属的一个公司就用ASP开发了一个B/S结构的HIS,几乎所有的功能都是用存储过程实现的。杭州妇幼保健医院在使用过程中由于种种原因要求改成C/S结构的,改的时候就发现当初大量的使用存储过程真是好啊!
全部用存储过程的方式有一个缺点就是程序在开发时调式相当麻烦,因为大家都知道程序错误大部分是出在代码与数据库交互的时候。回想起来也真是感慨,依稀记得当年在烟台的时候,当时是网通的一个项目,月底时他们从用户那所收的费用在帐上的金额与实际所收金额对不上,结果熬了一个通宵才搞定,最后找出原因来就是在存储过程中犯了个不起眼的错误。
第三种方式就是部分使用存储过程。就是在处理一些复杂的商务逻辑的时候用存储过程封装,一般比较简单的数据库操作还是用标准sql语句的方式。这样能保证程序的执行效率,同时也能保证一定的开发效率。这种方式也是在实际项目应用最多的方式。
具体一个项目采用哪种方式来做,是需要我们根据具体情况来确定的,不能一概而论。如果项目小、对程序的执行效率要求也不高。而且将来项目还可能做数据库移植的话,那就采用第一重方式是最好的;如果项目运行一定时间可能采用别的语言来重新开发,那就用第二种方式比较好。
如果是一个很多因素都不太确定的项目,个人认为一般采用第三方式比较好,就是一般的数据库操作都采用sql语句来实现,当然sql语句最好是标准的 sql语句,而那些相对比较烦琐的商务逻辑就用存储过程来封装好了。其实就是只在项目的某些特定的功能模块中采用存储过程的方式而已。这样做出来的项目既能灵活升级与移植,又能保证程序的执行效率。
扯远一点,如果是一个比较大型的ERP之类的项目,个人建议hibernate是个不错的选择,.net是nhibernate。数据库操作就省心了。没有用过的朋友可能刚开始有点排斥,这很正常,但是用熟练就能感觉它好用。

Ⅲ oracle 存储过程中的双重循环怎么写呢,在线等答案,菜鸟级别的,最好给个例子不胜感激。

先定义俩游标,数据如图,得出每个id下的两个项目

给你个例子吧,你这表我没摸清楚

declare

cursorcur_;

cursorcur_2(v_sidnumber)isselectsid,hobbyfrominfowheresid=v_sidandrownum<=2orderbysid;

begin

forr_cur1incur_1

loop

forr_cur2incur_2(r_cur1.sid)

loop

dbms_output.put_line(r_cur2.sid||','||r_cur2.hobby);

endloop;

endloop;

end;

Ⅳ mysql存储过程 游标双重循环

在老版本的MySQL 3.22中,MySQL的单表限大小为4GB,当时的MySQL的存储引擎还是ISAM存储引擎。但是,当出现MyISAM存储引擎之后,也就是从MySQL 3.23开始,MySQL单表最大限制就已经扩大到了64PB了(官方文档显示)。也就是说,从目前的技术环境来看,MySQL数据库的MyISAM存储 引擎单表大小限制已经不是有MySQL数据库本身来决定,而是由所在主机的OS上面的文件系统来决定了。

而MySQL另外一个最流行的存储引擎之一Innodb存储数据的策略是分为两种的,一种是共享表空间存储方式,还有一种是独享表空间存储方式。
当使用共享表空间存储方式的时候,Innodb的所有数据保存在一个单独的表空间里面,而这个表空间可以由很多个文件组成,一个表可以跨多个文件存在,所 以其大小限制不再是文件大小的限制,而是其自身的限制。从Innodb的官方文档中可以看到,其表空间的最大限制为64TB,也就是说,Innodb的单 表限制基本上也在64TB左右了,当然这个大小是包括这个表的所有索引等其他相关数据。
而当使用独享表空间来存放Innodb的表的时候,每个表的数据以一个单独的文件来存放,这个时候的单表限制,又变成文件系统的大小限制了。

Ⅳ 什么是存储过程有什么优点

存储过程是事先经过编译并存储在数据库中的一段SQL语句的集合,调用存储过程可以简化应用开发人员的很多工作,减少数据在数据库和应用服务器之间的传输,对于提高数据处理的效率是有好处的。

优点:

1、重复使用:存储过程可以重复使用,从而可以减少数据库开发人员的工作量。

2、减少网络流量:存储过程位于服务器上,调用的时候只需要传递存储过程的名称以及参数就可以了,因此降低了网络传输的数据量。

3、安全性:参数化的存储过程可以防止SQL注入式攻击,而且可以将Grant、Deny以及Revoke权限应用于存储过程。

(5)存储过程支持重跑扩展阅读

存储过程的缺点:

1、更改比较繁琐:如果更改范围大到需要对输入存储过程的参数进行更改,或者要更改由其返回的数据,则仍需要更新程序集中的代码以添加参数、更新 GetValue() 调用,等等,这时候估计比较繁琐。

2、可移植性差:由于存储过程将应用程序绑定到 SQL Server,因此使用存储过程封装业务逻辑将限制应用程序的可移植性。如果应用程序的可移植性在您的环境中非常重要,则需要将业务逻辑封装在不特定于 RDBMS 的中间层中。