問題描述

我發(fā)現(xiàn)很多教科書，數(shù)據(jù)庫教程視頻都涉及到了存儲過程，但是我看過很多開源的php項目，里面幾乎就沒有用到存儲過程啊，我看過java項目倒是有部分項目用到過存儲過程，這是為什么呢？

已經(jīng)從業(yè)或者開發(fā)過大型項目的程序員們你們在實際工作中用到過他嗎？

還有就是存儲過程里面的邏輯幾乎我都可以用程序（java，php）寫，為什么還要直接在數(shù)據(jù)庫里面寫呢？（換句話說：存儲過程的意義是什么？）

問題解答

一、存儲過程是非常有用滴。例如，在常見的登錄場景中，需要記錄用戶的登入記錄，你可以使用編程語言來實現(xiàn):

db.connect( 'db_host' ).execute_sql( 'select count(*) from user_info_table where username = ’you’ and pass=’123’ ' ); db.connect( 'db_host' ).execute_sql( 'insert into login_table( user_name, log_time )values( ’you’, ’2017_01_05’ ) ' );

在這里，第1步首先判斷用戶存不存在，第2步記錄用戶登錄日志。

存儲過程實現(xiàn)：login_user_and_save_result()的功能是執(zhí)行用戶登錄操作、并記錄用戶的登錄日志。

db.connect( 'db_host' ).execute_sql( 'call login_user_and_save_result(’you’, ’123’) ' );

區(qū)別在于，編程語言實現(xiàn)需要執(zhí)行2次數(shù)據(jù)庫連接connect操作、2次編譯sql操作execute_sql；login_user_and_save_result()則只需要1次connect，0次編譯execute_sql操作，因為存儲過程在創(chuàng)建之初就已經(jīng)編譯好了，只需要傳參數(shù)就可以了。這樣在用戶量逐步增長的情況下，存儲過程可以為服務器省很多帶寬、系統(tǒng)資源消耗，優(yōu)勢會慢慢顯示出來。

如果，你的boss讓你再加一層邏輯，只允許用戶3次登錄嘗試，3次失敗后，不允許登錄。在編程語言級別的數(shù)據(jù)庫操作會變的更加復雜一點。

arr_result = db.connect( 'db_host' ).execute_sql( 'select count(*) from user_info_table where username = ’you’ and pass=’123’ and enable_login = 1' ); // if( arr_result != 1 ) { //更新登入失敗次數(shù) db.connect( 'db_host' ).execute_sql( 'insert user_login_fail(username, pass) values( ’you’, ’pass’ ) ' ); } fail_count = db.connect( ’db_host’ ).execute_sql( 'select count(*) from user_login_fail where username = ’you’' ); if( fail_count > 3 ) { db.connect( 'db_host' ).execute_sql( 'update user_info_table set enable_login = 0' ); }

在這里，你可以發(fā)現(xiàn)編程語言需要頻繁的連接db、或者說要和數(shù)據(jù)庫保持長時間的網(wǎng)絡連接。如果，你把這些登錄邏輯都放在login_user_and_result()里實現(xiàn)，你要做的只是傳入?yún)?shù)username、pass，系統(tǒng)也只需要做1次連接db、0次編譯，簡單很多。

二、存儲過程的作用不只在資源消耗上。現(xiàn)在，你的程序有兩種方式登錄，一種是在web端登錄，一種是原生client端登錄。假設，web端是使用java web實現(xiàn)，client端是使用visual c++來實現(xiàn)。如果，java web 和 visual c++在登錄的時候都調(diào)用login_user_and_result()，就可以保持用戶一致的登錄行為，避免開發(fā)人員分別實現(xiàn)導致其他問題。其實，你還可以給存儲過程添加各種數(shù)據(jù)庫級別的權限，統(tǒng)一控制登入權限。

我覺得存儲過程主要有兩個優(yōu)勢。一是在數(shù)據(jù)庫端執(zhí)行，避免網(wǎng)絡通訊開銷，從而效率較高。二是存儲過程可以直接利用數(shù)據(jù)庫提供的一些高級抽象，比如事務、觸發(fā)器、重寫規(guī)則等。

如果完全不用存儲過程，數(shù)據(jù)庫只是一個提供增刪改的存儲后端罷了，它提供的高級功能就浪費了。可以用存儲過程構建業(yè)務功能，前端只是調(diào)用這些功能，類似于API的效果。

實施,運維可以自己改，不然屁大點業(yè)務都要返回到開發(fā)這邊改代碼，編譯，發(fā)補丁

我的項目中，沒有使用到存儲過程。倒是用過視圖！項目大些的公司可能有些需要，有專門Dba的單位！

ods，數(shù)據(jù)倉庫等傳統(tǒng)數(shù)據(jù)中心的數(shù)據(jù)批處理，或者olap還是會用存儲過程的

有DBA用存儲過程或者簡單的邏輯用，日志寫到數(shù)據(jù)庫中...個人覺得寫到代碼里簡單些

效率高，有時候職責分得很細的時候后端未必能隨意訪問數(shù)據(jù)庫

我所在的項目里存儲過程是用得比較多，特別是報表，大部分用存儲過程。除了上面的幾個優(yōu)點，還有就是存儲過程的擴展性會比較好，比如說跨庫、分表union，一些動態(tài)拼接sql的，存儲過程方便，也直觀，對于日后分布式，也只是在存儲過程內(nèi)拼接修改。

我一般用來做數(shù)據(jù)整理，遷移。比如網(wǎng)站整改，數(shù)據(jù)結構變了，某某表被拆了，某某表合并了，某某字段數(shù)據(jù)格式有變等等情況，反正我只在站點升級的時候需要用到。其他查詢一般能用代碼實現(xiàn)的都不想用存儲過程實現(xiàn)

有逼格的公司，會專門有DBA這樣一個職位，才看不上程序員寫的SQL，復雜的業(yè)務寫個幾千行存儲過程實現(xiàn)。存儲過程本身的優(yōu)點就不具體說了。