當前位置:首頁 » 服務存儲 » 存儲過程支持重跑
擴展閱讀
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 的中間層中。