現在不寫存儲過程了嗎

1. 現在寫那個sql代碼是不是都要用存儲過程，這樣有什麼好處

不需要每條sql都要用存儲過程，存儲過程有優點也有缺點的
優點：
* 存儲過程的能力大大增強了SQL語言的功能和靈活性。存儲過程可以用流控制語句編寫，有很強的靈活性，可以完成復雜的判斷和較復雜的 運算。
* 可保證數據的安全性和完整性。
* 在運行存儲過程前，資料庫已對其進行了語法和句法分析，並給出了優化執行方案。這種已經編譯好的過程可極大地改善SQL語句的性能。由於執行SQL語句的大部分工作已經完成，所以存儲過程能以極快的速度執行。
* 可以降低網路的通信量。
* 使體現企業規則的運算程序放入資料庫伺服器中，以便：
# 集中控制。
# 當企業規則發生變化時在伺服器中改變存儲過程即可，無須修改任何應用程序。

簡單講：
1.存儲過程只在創造時進行編譯，以後每次執行存儲過程都不需再重新編譯，而一般SQL語句每執行一次就編譯一次,所以使用存儲過程可提高資料庫執行速度。
2.當對資料庫進行復雜操作時(如對多個表進行Update,Insert,Query,Delete時)，可將此復雜操作用存儲過程封裝起來與資料庫提供的事務處理結合一起使用。
3.存儲過程可以重復使用,可減少資料庫開發人員的工作量
4.安全性高,可設定只有某些用戶才具有對指定存儲過程的使用權

缺點：
1：調試麻煩
2：移植問題，資料庫端代碼當然是與資料庫相關的。但是如果是做工程型項目，基本不存在移植問題。
3：重新編譯問題，因為後端代碼是運行前編譯的，如果帶有引用關系的對象發生改變時，受影響的存儲過程、包將需要重新編譯。
4： 如果在一個程序系統中大量的使用存儲過程，到程序交付使用的時候隨著用戶需求的增加會導致數據結構的變化，接著就是系統的相關問題了，最後如果用戶想維護該系統可以說是很難很難、而且代價是空前的，維護起來更麻煩。

2. 現在oracle在實際運用中存儲過程用的多嗎

這個是必須使用的，我們公司的項目中就使用到了
*1) 存儲過程幫助在資料庫層聚集T-SQL代碼。嵌入即席SQL的網站或應用程序在應用環境下很難修改，當即席SQL嵌入在應用程序內的時候，你可能會花費太多時間試圖找到和調試嵌入的SQL。-- 一旦找到了bug，你可能就需要重新編譯可執行程序，引起不必要的應用程序臨時停止或痛苦的應用程序部署。如果把T-SQL集中到存儲過程中去，-- 你就只需要集中在一個地方來查詢SQL代碼或SQL批處理。如果你能正確地為代碼建立文檔並對代碼標准化，存儲過程就會提升整個應用程序的可支持性。

-- *2) 存儲過程幫助大的即席查詢減少網路流量。編寫應用程序調用而不是500行的SQL調用來執行存儲過程，對網路以及應用程序的性能有正面影響，特別是當調用在一分鍾內重復數千次時。

-- *3) 存儲過程促進代碼的可利用性。例如，如果你的網站應用程序使用一個下拉菜單來包含一組城市，並且這個下拉菜單用於很多網頁，-- 你可以在每個頁面調用存儲過程而不是在多個地方嵌入相同的SQL。

-- *4) 存儲過程淡化數據獲取的方法。如果你修改了提供源數據的基本表，存儲過程(和視圖相似)能讓應用程序對這個修改透明。這樣就不需要修改應用程序底層的代碼就能修改。-- 你可以把老的表換成新的，而且只要同樣的列和數據類型返回給應用程序，則應用程序完全不知情。

-- *5) 與視圖不同，存儲過程可以利用流控制技術、臨時表、表變數等。

-- *6) 存儲過程對查詢響應時間的影響比較穩定。如果你使用大量的即席查詢，可能會注意到有時候從查詢中返回結果所花的時間變化很大

3. java軟體開發一定要會存儲過程嗎

不需要了~都用hibernate操作資料庫了~C#存儲過程用的多

4. 請問什麼年代了，還不用存儲過程。服了。

存儲過程可以使得程序執行效率更高、安全性更好。因為在客戶端寫SQL需要先分析再執行，但是在伺服器端存儲過程建立之後已經編譯並且儲存到資料庫，這樣客戶端只需要直接用便可以了。並且可以防止SQL注入攻擊。等等這些針對存儲過程的普遍認知的好處就不細說了。
我打算從編碼級別談談這個問題。
1、代碼級別提高安全性。在程序員編碼的時候往往會自己寫SQL語句，這樣會導致直接將後台資料庫的許多信息暴露出來。
2、防止SQL語句泛濫。程序員編碼的時候總是將許多SQL語句重復的寫來寫去，這樣既增加了系統的代碼量，又降低了系統的執行效率。如果使用統一的存儲過程，這樣可以將程序員的側重點放在介面的參數上。
3、增強分工降低了程序員的工作量。如果能增強分工能力那樣更能提高效率，例如有的程序員主要關注界面交互的，有的程序員需要關注服務介面，而有的程序員需要關注伺服器相關業務，這樣才能做到分工明確。而現在的情況是一個程序員從前到後全部都涉及。這樣不利於工作的針對性。如果使用存儲過程的話，那麼程序員在編碼的時候便可以很輕松的將業務需要的參數按照要求傳遞進去便可以了。而不必去過多的關注其中的實現。可以將更多的精力轉移到相應的其他操作中去。
4、應對變化的業務操作。如果不使用存儲過程的話，當業務變更的時候，一般的處理方式是找出變更的業務，然後將那部分表的操作進行變更，然後將變更涉及到的模塊重新編譯。這樣的做法會降低系統開發的反應時間，不能盡快的做到應對。但是如果使用存儲過程的話，將業務的操作部分移到伺服器端，這樣的話，相應的業務變更的時候，只需要在伺服器端更新相應的存儲過程便可達到目的，系統則沒必要過多的去關注。這樣便增加了系統的反應時間，達到盡快應對的效果。

5. 存儲過程的問題，請高手幫忙

不用寫存儲過程，直接一個查詢語句就可以了

Access寫法
select 班級名稱, sum(iif(分數>=90,1,0)) as A, sum(iif(分數>=80 and 分數<90,1,0)) as B, sum(iif(分數>=70 and 分數<80,1,0)) as C, sum(iif(分數>=60 and 分數<70,1,0)) as D, sum(iif(分數<60,1,0)) as E from 成績表 group by 班級名稱

Sql2000寫法
select 班級名稱, sum(case when 分數>=90 then 1 else 0 end) as A, sum(case when 分數>=80 and 分數<90 then 1 else 0 end) as B, sum(case when 分數>=70 and 分數<80 then 1 else 0 end) as C, sum(case when 分數>=60 and 分數<70 then 1 else 0 end) as D, sum(case when 分數<60 then 1 else 0 end) as E from 成績表 group by 班級名稱

A 為 90分以上的人數，B 為 80~90分的人數，C 為 70~80分的人數，D 為 60~70分的人數，E 為 60分一下的人數

6. 現在在c#項目開發中「存儲過程」用的多嗎

存儲過程用的還是挺多的，因為存儲過程可以避免SQL注入攻擊，同時執行效率也比直接使用SQL語句要高得多。現在你可以選擇LINQ，使用更加方便，而且是面向對象的，即把SQL中每一行當做一個對象來操作，同時語句也比較直觀。

7. mysql 為什麼沒有存儲過程

我不是這樣理解的
1對於某些返回行紀錄很多的情況，存儲過程發揮很大作用，第1次編譯之後，之後不用再編譯，直接走執行計劃
理論上要快很多的
2特別某些大表，復雜應用有時候必須用存儲過程

我回憶很多年前作項目，有專家指導團隊要求所有SQL代碼全部轉為存儲過程----一方面安全性，另1方面速度理論要快

現在我當前環境確實是並發量大的應用，我覺得對於單條插入 刪除 修改等操作可以不用
但是類似 SQL我覺得還是應該用存儲過程 （現在我不知道mysql的內部機智）

8. 現在編程開發是不是都普遍使用存儲過程來操作資料庫了

您好，1. 直接在程序中構造SQL的話後期維護, 比如表欄位的增減, 有可能會影響到你SQL語句的可執行性, 那個時候你就必須要修改程序源碼, 可能的結果是牽一發而動全身, 如果用存儲過程, 那麼只要更新存儲過程就可以了, 便於維護！
2. 如果不法分子破解你的程序, 存儲過程是放在你的資料庫伺服器上的！那麼光得到你的存儲過程名稱, 沒有實際的實現代碼~~所以使用存儲過程的安全性相對較高！
3. 存儲過程的執行效率較高, 速度快！復雜的查詢, 對速度的要求還是有講究的。

9. 題外話，為什麼不用資料庫的存儲過程

不建議使用存儲過程的原因
其一：各種資料庫的存儲過程語法相差很大，給將來的資料庫移植帶來很大的困難
其二：不利於版本控制，代碼無法Diff和回滾，多人編輯無法同步。
雖然資料庫建模工具可以把腳本保存為文件，然後進行Diff，但終究功能有限。
其三：編碼不便，其實也就是說資料庫腳本語言功能有限，
無法定義數組，集合，為了循環需要使用效率低下的游標
其四：調試功能不強。
雖然在資料庫客戶端工具里，也可以調試,卻也和現在功能強大IDE集成工具的調試
卻不可同日而語。而且現在一般調試是由應用程序發起的，從應用程序卻又無法
跟蹤調試回存儲過程中。所以必須兩處調試，終究不便。
其五：存儲過程會調用函數，視圖或者別的存儲過程，但是資料庫的編輯工具，
不像時下的開發工具，能夠准確定位對象或對象方法，所以帶來維護，修改的困難。
其五：現在大多應用級系統會分層處理，數據層，業務層，界面層。
我們把大量使用存儲過程的C/S或者B/S系統稱為兩層半，也就是說存儲過程就是我們
說的半層，也就是把大量業務邏輯放在存儲過程里。業務邏輯往往是系統的核心所在，
往往修改會很頻繁，存儲過程的使用會帶來修改困難，修改流程困難，調試麻煩，
所以付出的代價是很大的。
其六：面向業務編程，而不要面向數據編程。
面向業務編程，其實也就是之前我說的領域邏輯模式中的領域模型，也是我不贊成用存儲過程
的根本原因。
如果大量用到存儲過程，就勢必會和數據表、欄位、欄位類型等等關系形資料庫打交道，
面向對象的優勢就體現不了，也就無從談起繼承，多態，設計模式等來適應業務變化。
很多J2EE的項目甚至不用存儲過程，也照樣開發的很好。

其七：也許會遇到業務邏輯特別復雜的情況，遇到這種情況，我的感覺是你應該回頭看看業務建模是否合理。

10. mysql 為什麼不用存儲過程

我不是這樣理解的
1對於某些返回行紀錄很多的情況，存儲過程發揮很大作用，第1次編譯之後，之後不用再編譯，直接走執行計劃
理論上要快很多的
2特別某些大表，復雜應用有時候必須用存儲過程

我回憶很多年前作項目，有專家指導團隊要求所有SQL代碼全部轉為存儲過程----一方面安全性，另1方面速度理論要快

現在我當前環境確實是並發量大的應用，我覺得對於單條插入 刪除 修改等操作可以不用
但是類似 SQL我覺得還是應該用存儲過程 （現在我不知道mysql的內部機智）