專案暫時告一段落，下面就工作中的情況以及個人遇到的問題進行一下個人總結：
首先總結一下在專案中學到的東西
1、對游標的使用：在剛剛開始編碼的時候，學會了使用游標，開始的時候覺得它對錶的遍歷很方便，但是在專案中慢慢發現，如果在查詢中加入游標，在資料量相對較大時，效能下降很多。所以，對游標的使用應盡量慎重。
2、對函式的建立：在檢視中有時會用到一些函式列，函式中的查詢不可以查詢本身所在的檢視，因為這樣也會大大降低查詢的效率。
3、對float型別的認識：在做專案中，使用了float型別來定義一些列，如：price，但是發現了很多問題
當值的位數大於6位是float型再轉varchar型的時候會變為科學技術法顯示
此時只好將float型轉換成numeric型，在轉換成varchar
float型變數在存入值時，有時值得大小會發生改變。這個現象發生在對**儲存時，如：儲存乙個3.8，但到了資料庫中變成了3.80001124或3.79998999等
在sqlserver的幫助中是這樣描述float型別的：用於表示浮點數字資料的近似數字資料型別。浮點資料為近似值；並非資料型別範圍內的所有資料都能精確地表示。
所以在今後的型別定義時，個人認為應避開使用此型別
4、對檢視的修改：在專案中發現如果建立好的檢視在需要修改時最要使用雙擊檢視後直接寫入t-sql進行修改，如果使用修改檢視的話，修改檢視中t-sql有時會發生變化，但是不容易發現。
5、對綜合查詢檢視的使用：在專案中曾建立過功能檢視v_sign_signinfo，在開始只是覺得方便，但是隨著專案的開發，大家都在想這個檢視中加入新的列或函式，慢慢的這個檢視的查詢效率開始降低，隨之而來的就是使用到它的查詢頁面的效率也開始降低，同時幾乎所有的頁面都存在很多不必要的查詢。
6、對併發性的認識：在此次專案的初始測試階段，主觀分打分，投票都出現了十分嚴重的併發性問題，事務發生死鎖犧牲，當時的環境是多人（15人左右）在區域網內對指定的幾個表同時進行大量查詢操作（有查詢有修改），此時事務不可放在上層，因為這樣如果上層是迴圈操作的話會導致上層的事務因未完成而不放棄資源的占用，而下層（sqlserver中）會因為原子操作的完成而讓其他事務占用資源，此時的解決辦法是：把迴圈的update的操作放入乙個儲存過程。上層的不加入事務，而在儲存過程中加入事務，並提高儲存過程的事務級別，儲存過程中的**如下：
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
endupdate 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
使用過程表了提高查詢效率，減少頁面中的多餘查詢。雖說效能以後了很大的提高，事務不在形成環狀的死鎖，成線性的佇列狀態，但在快速頻繁的操作中有時還是出現事務報錯問題，但是問題發生的概率已降低了很多。
其次總結一下此次的感想
1、想好了在做：這是我參加這次專案中感受最深的事情，接到乙個新的任務後不應該馬上就動手寫，先應完全掌握需求，明確你要實現的是什麼，然後考慮如何實現，有必要畫一些流程圖來幫助，最後才是編碼。因為如果提前不想好，而做完之後修改很有可能修改的越來越亂。
2、對於關鍵點的記錄：在編碼過程中有時會遇到一些不合法的操作，但為了讓使用者的整體操作完成，對於這些不合法操作我們做了相應的標示，但是由於工作重心的轉移，我們很有可能忘記當時的想法，以至於忽略了對這個關鍵點存在的問題，最終導致其成為整個專案中的乙個死穴。所以，在今後的工作中遇到關鍵點時，應及時記錄，並想出更合理的解決辦法，以至於出現的問題不止於流入下乙個階段。
3、對需求的了解和對客戶工作方式及內容的了解：在這次專案開發過程中，除了在系統的執行的效能上，在使用者的使用上的改動也十分的頻繁。開始我們完全歸咎於客戶的需求不明。但在事後的冷靜思考中覺得，其實我們也有原因，我覺得原因在於對使用者的需求了解不夠透徹，但更重要的是我們對客戶的工作方式以及工作的內容的忽視，舉例說：我們開始在做對產品的查詢的時候是先查生產企業，再查產品，實際上在和使用者的交流中，這種查詢給他們帶來了很大的不便。使用者的關注點是先在產品上，然後也許關注一下生產企業。類似的問題還有一些，包括對一些關鍵資料的處理。如：對包裝規格的處理，在看其他**機構的公市資料發現，他們對於產品包裝的處理只有一級（如：1支/盒），對於**單位的選取也有相應的政策規定，如：此種類產品的包裝單位就是支，如果這樣處理資料，既簡單又安全。所以在今後的工作中我覺得還是應該首先做好的是要深入了解使用者需求、工作方式及工作內容（當然在不違法的前提下）
4、對於專案中公市等滾屏處理的地方還有待考慮，雖然此功能的實現是使用者的意思，但是，在使用過程中發現，此頁面的資料量是十分大的（大多在
1500
條以上）。這樣就加大了客戶端對伺服器端生成
html
語句翻譯的量。在實施過程中有的使用者就反映瀏覽器登陸後十多分鐘沒有反映。相比較下，其他**機構的定時翻頁就有很多的優點。
第一次衝刺 個人工作總結04
昨天幹了什麼 昨天在一起討論了介面的樣式，介面的ui元件怎麼設計，怎麼進行排版，只是制定了開發的目標 今天準備幹什麼 今天準備進行實際的介面的開發，我開發的是活動詳情介面，所以需要設計幾個文字顯示框，顯示活動的建立者 活動的標題 活動的詳細介紹 活動的人數情況，以及加入或退出按鈕的設計 遇到的困難 ...
第一次個人總結
最近半個月在學習爬蟲，收穫很大，所以來做乙個總結 寫了這麼久爬蟲，其實爬蟲的本質就是模仿瀏覽器向服務傳送請求，然後伺服器給我響應的資料，就像是和伺服器交換物品一樣，我先給他乙個，他再給我乙個，只不過我給他的是請求物件，他給我的是響應的資料，僅此而已 爬蟲的難點在於我給他的資料他不要，他告訴我你給的東...
第一次參加DC比賽總結
第一次參加dc比賽，選擇乙個不太難的 遊戲玩家付費金額 大賽 進行，雖說看了各種 top 1 top 10 top 5 等文章，成績依然還是不理想。總結原因發現還是在對資料的了解和特徵工程技巧上沒有下足功夫或者沒有足夠的經驗，下面就細節問題和環節作簡要總結。資料的第一映像非常重要，決定了下一步資料處...