第一次參加項(xiàng)目個人工作總結(jié) 項(xiàng)目暫時告一段落，下面就工作中的情況以及個人遇到的問題進(jìn)行一下個人總結(jié)：
首先總結(jié)一下在項(xiàng)目中學(xué)到的東西
1、對游標(biāo)的使用：在剛剛開始編碼的時候，學(xué)會了使用游標(biāo)，開始的時候覺得它對表的遍歷很方便，但是在項(xiàng)目中慢慢發(fā)現(xiàn)，如果在查詢中加入游標(biāo)，在數(shù)據(jù)量相對較大時，性能下降很多。所以，對游標(biāo)的使用應(yīng)盡量慎重。
2、對函數(shù)的創(chuàng)建：在視圖中有時會用到一些函數(shù)列，函數(shù)中的查詢不可以查詢本身所在的視圖，因?yàn)檫@樣也會大大降低查詢的效率。
3、對float類型的認(rèn)識：在做項(xiàng)目中，使用了float類型來定義一些列，如：Price，但是發(fā)現(xiàn)了很多問題
當(dāng)值的位數(shù)大于6位是float型再轉(zhuǎn)varchar型的時候會變?yōu)榭茖W(xué)技術(shù)法顯示
??? 此時只好將float型轉(zhuǎn)換成numeric型，在轉(zhuǎn)換成varchar
float型變量在存入值時，有時值得大小會發(fā)生改變。這個現(xiàn)象發(fā)生在對報(bào)價(jià)保存時，如：保存一個3.8，但到了數(shù)據(jù)庫中變成了3.80001124或3.79998999等
在SqlServer的幫助中是這樣描述float類型的：用于表示浮點(diǎn)數(shù)字?jǐn)?shù)據(jù)的近似數(shù)字?jǐn)?shù)據(jù)類型。浮點(diǎn)數(shù)據(jù)為近似值；并非數(shù)據(jù)類型范圍內(nèi)的所有數(shù)據(jù)都能精確地表示。
所以在今后的類型定義時，個人認(rèn)為應(yīng)避開使用此類型
4、對視圖的修改：在項(xiàng)目中發(fā)現(xiàn)如果創(chuàng)建好的視圖在需要修改時最要使用雙擊視圖后直接寫入T-Sql進(jìn)行修改，如果使用修改視圖的話，修改視圖中T-Sql有時會發(fā)生變化，但是不容易發(fā)現(xiàn)。
5、對綜合查詢視圖的使用：在項(xiàng)目中曾建立過功能視圖V_Sign_SignInfo，在開始只是覺得方便，但是隨著項(xiàng)目的開發(fā)，大家都在想這個視圖中加入新的列或函數(shù)，慢慢的這個視圖的查詢效率開始降低，隨之而來的就是使用到它的查詢頁面的效率也開始降低，同時幾乎所有的頁面都存在很多不必要的查詢。
6、對并發(fā)性的認(rèn)識：在此次項(xiàng)目的初始測試階段，主觀分打分，投票都出現(xiàn)了十分嚴(yán)重的并發(fā)性問題，事務(wù)發(fā)生死鎖犧牲，當(dāng)時的環(huán)境是多人（15人左右）在局域網(wǎng)內(nèi)對指定的幾個表同時進(jìn)行大量查詢操作（有查詢有修改），此時事務(wù)不可放在上層，因?yàn)檫@樣如果上層是循環(huán)操作的話會導(dǎo)致上層的事務(wù)因未完成而不放棄資源的占用，而下層（SqlServer中）會因?yàn)樵硬僮鞯耐瓿啥屍渌聞?wù)占用資源，此時的解決辦法是：把循環(huán)的Update的操作放入一個存儲過程。上層的不加入事務(wù)，而在存儲過程中加入事務(wù)，并提高存儲過程的事務(wù)級別，存儲過程中的代碼如下：
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
--SET LOCK_TIMEOUT 1800
Begin Tran Tran1
?While(Len(@StrElementID)>0)
??Begin
???Set @CountElement = PatIndex('%,%',@StrElementID)
???Set @TempElement = Left(@StrElementID,@CountElement-1)
???Set @CountPoint = PatIndex('%,%',@StrPoint)
???Set @TempPoint = Left(@StrPoint,@CountPoint-1)
???Update esintypzb.T_Bid_MediSubj set Point = @TempPoint ?--更新打分記錄
????Where FK_Element_ID = @TempElement and FK_Expert_ID = @FK_Expert_ID and
????FK_Medicine_ID = @FK_Medicine_ID
???Set @StrElementID = Right(@StrElementID,Len(@StrElementID)-@CountElement)
???Set @StrPoint = Right(@StrPoint,Len(@StrPoint)-@CountPoint)
???If @@Error<>0 Goto Error
??End
?Update esintypzb.T_Bid_MediBoundTemp Set SumPoint = @SumPoint Where FK_Expert_ID = @FK_Expert_ID And FK_Medicine_ID = @FK_Medicine_ID
?If @@Error<>0 Goto Error
??Set @Flag = 1
Commit Tran Tran1
Return
Error:
Set @Flag = 0
RollBack Tran Tran1
使用過程表了提高查詢效率，減少頁面中的多余查詢。雖說性能以后了很大的提高，事務(wù)不在形成環(huán)狀的死鎖，成線性的隊(duì)列狀態(tài)，但在快速頻繁的操作中有時還是出現(xiàn)事務(wù)報(bào)錯問題，但是問題發(fā)生的概率已降低了很多。
其次總結(jié)一下此次的感想
1、想好了在做：這是我參加這次項(xiàng)目中感受最深的事情，接到一個新的任務(wù)后不應(yīng)該馬上就動手寫，先應(yīng)完全掌握需求，明確你要實(shí)現(xiàn)的是什么，然后考慮如何實(shí)現(xiàn)，有必要畫一些流程圖來幫助，最后才是編碼。因?yàn)槿绻崆安幌牒?#xff0c;而做完之后修改很有可能修改的越來越亂。
2、對于關(guān)鍵點(diǎn)的記錄：在編碼過程中有時會遇到一些不合法的操作，但為了讓用戶的整體操作完成，對于這些不合法操作我們做了相應(yīng)的標(biāo)示，但是由于工作重心的轉(zhuǎn)移，我們很有可能忘記當(dāng)時的想法，以至于忽略了對這個關(guān)鍵點(diǎn)存在的問題，最終導(dǎo)致其成為整個項(xiàng)目中的一個死穴。所以，在今后的工作中遇到關(guān)鍵點(diǎn)時，應(yīng)及時記錄，并想出更合理的解決辦法，以至于出現(xiàn)的問題不止于流入下一個階段。
3、對需求的了解和對客戶工作方式及內(nèi)容的了解：在這次項(xiàng)目開發(fā)過程中，除了在系統(tǒng)的執(zhí)行的性能上，在用戶的使用上的改動也十分的頻繁。開始我們完全歸咎于客戶的需求不明。但在事后的冷靜思考中覺得，其實(shí)我們也有原因，我覺得原因在于對用戶的需求了解不夠透徹，但更重要的是我們對客戶的工作方式以及工作的內(nèi)容的忽視，舉例說：我們開始在做對產(chǎn)品的查詢的時候是先查生產(chǎn)企業(yè)，再查產(chǎn)品，實(shí)際上在和用戶的交流中，這種查詢給他們帶來了很大的不便。用戶的關(guān)注點(diǎn)是先在產(chǎn)品上，然后也許關(guān)注一下生產(chǎn)企業(yè)。類似的問題還有一些，包括對一些關(guān)鍵數(shù)據(jù)的處理。如：對包裝規(guī)格的處理，在看其他代理機(jī)構(gòu)的公市數(shù)據(jù)發(fā)現(xiàn)，他們對于產(chǎn)品包裝的處理只有一級（如：1支/盒），對于報(bào)價(jià)單位的選取也有相應(yīng)的政策規(guī)定，如：此種類產(chǎn)品的包裝單位就是支，如果這樣處理數(shù)據(jù)，既簡單又安全。所以在今后的工作中我覺得還是應(yīng)該首先做好的是要深入了解用戶需求、工作方式及工作內(nèi)容（當(dāng)然在不違法的前提下）
4、對于項(xiàng)目中公市等滾屏處理的地方還有待考慮，雖然此功能的實(shí)現(xiàn)是用戶的意思，但是，在使用過程中發(fā)現(xiàn)，此頁面的數(shù)據(jù)量是十分大的（大多在1500條以上）。這樣就加大了客戶端對服務(wù)器端生成HTML語句翻譯的量。在實(shí)施過程中有的用戶就反映瀏覽器登陸后十多分鐘沒有反映。相比較下，其他代理機(jī)構(gòu)的定時翻頁就有很多的優(yōu)點(diǎn)。

總結(jié)

以上是生活随笔為你收集整理的第一次参加项目个人工作总结 （转）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。