存儲過程的優(yōu)缺點(diǎn)個人總結(jié)-展示頁
2024-10-25 08:32本頁面
【正文】 示數(shù)據(jù)庫中所有存儲的存儲過程基本信息，包括所屬數(shù)據(jù)庫，存儲過程名稱，創(chuàng)建時間等 create procedure sp_name 顯示某一個存儲過程的詳細(xì)信息mysql存儲過程基本函數(shù)CHARSET(str)//返回字串字符集 CONCAT(string2 [,...])//連接字串INSTR(string ,substring)//返回substring首次在string中出現(xiàn)的位置,不存在返回0 LCASE(string2)//轉(zhuǎn)換成小寫LEFT(string2 ,length)//從string2中的左邊起取length個字符 LENGTH(string)//string長度一起推論壇第四篇：課題：SQLServer存儲過程返回值總結(jié)SQLServer存儲過程返回值總結(jié)(即存儲過程語句中沒有return之類的語句)用方法 int count = ExecuteNonQuery(..)執(zhí)行存儲過程其返回值只有兩種情況(1)假如通過查詢分析器執(zhí)行該存儲過程，在顯示欄中假如有影響的行數(shù)，則影響幾行count就是幾(2)假如通過查詢分析器執(zhí)行該存儲過程，在顯示欄中假如顯示39。也可以給區(qū)塊起別名，如： lable:begin end lable。存儲過程最大的缺點(diǎn)是SQL語言本身的局限性——我們不應(yīng)該用存儲過程處理復(fù)雜的業(yè)務(wù)邏輯——讓SQL回歸它“結(jié)構(gòu)化查詢語言”的功用吧。除了少數(shù)有語言潔癖的人，我相信精通SQL只是時間問題?！灰Γ@是真的，我面試過N多新人，都不知道如何創(chuàng)建全局臨時表、不知道having、不知道聚集索引和非聚集索引，更別提游標(biāo)和提交叉表查詢了。（水平或垂直切割）。雖然有全局臨時表之類的方法可以做緩存，但同樣加重了數(shù)據(jù)庫的負(fù)擔(dān)。基本上沒有較好的調(diào)試器，很多時候是用print來調(diào)試，但用這種方法調(diào)試長達(dá)數(shù)百行的存儲過程簡直是噩夢。這一點(diǎn)算致命傷。況且放在ORM中還能用二級緩存，有些時候效率還會更高。這一點(diǎn)算是ORM的軟肋。領(lǐng)域模型和數(shù)據(jù)模型的設(shè)計(jì)可能不是同一個人（一個是SA，另一個是DBA），兩者的分歧可能會很大——這不奇怪，一個是以O(shè)O的思想來設(shè)計(jì)，一個是結(jié)構(gòu)化的數(shù)據(jù)來設(shè)計(jì)，大家互不妥協(xié)——你說為了軟件的彈性必須這么設(shè)計(jì)，他說為了效率必須那樣設(shè)計(jì)，為了抹平鴻溝，就用存儲過程來做數(shù)據(jù)存儲的邏輯映射（把屬性映射到字段）。但我們的應(yīng)付服務(wù)器通常與數(shù)據(jù)庫是在同一內(nèi)網(wǎng)，大數(shù)據(jù)的訪問的瓶頸會是硬盤的速度，而不是網(wǎng)速。但這個效率真是沒太大影響。但這一點(diǎn)便利被許多人濫用了。本人經(jīng)驗(yàn)和水平有限，總結(jié)有所偏頗，還請大家糾察。近來做新系統(tǒng)的時候，我采用了三層架構(gòu)，拋棄存儲過程改用ORM。存儲過程最大的缺點(diǎn)是SQL語言本身的局限性——我們不應(yīng)該用存儲過程處理復(fù)雜的業(yè)務(wù)邏輯——讓SQL回歸它“結(jié)構(gòu)化查詢語言”的功用吧。除了少數(shù)有語言潔癖的人，我相信精通SQL只是時間問題?！灰?，這是真的，我面試過N多新人，都不知道如何創(chuàng)建全局臨時表、不知道having、不知道聚集索引和非聚集索引，更別提游標(biāo)和提交叉表查詢了。（水平或垂直切割）。雖然有全局臨時表之類的方法可以做緩存，但同樣加重了數(shù)據(jù)庫的負(fù)擔(dān)。好吧，這一點(diǎn)不算啥，C/java一樣能寫出噩夢般的代碼。缺點(diǎn)，加上了一些控制（賦值、循環(huán)和異常處理等），但不是
研究報(bào)告相關(guān)推薦
鄂ICP備17016276號-1