學習中的快樂,，產(chǎn)生于對學習內(nèi)容的興趣和深入,。世上所有的人都是喜歡學習的，只是學習的方法和內(nèi)容不同而已,。優(yōu)質(zhì)的心得體會該怎么樣去寫呢,？下面我?guī)痛蠹艺覍げ⒄砹艘恍﹥?yōu)秀的心得體會范文,，我們一起來了解一下吧。

數(shù)據(jù)庫實訓心得體會篇一

經(jīng)過之前的在校學習,，對程序設計有了一定的認識與理解,。在校期間，一直都是學習理論知識,，沒有機會去參與項目的開發(fā),。所以說實話，在實訓之前,，軟件項目開發(fā)對我來說是比較抽象的,，一個完整的項目要怎么分工以及完成該項目所要的步驟也不是很明確,。而經(jīng)過這次實訓，讓我明白了一個完整項目的開發(fā),，必須由團隊來分工合作,，并在每個階段中進行必要的總結與論證,。

一個完整項目的開發(fā)它所要經(jīng)歷的階段包括：遠景范圍規(guī)劃和用例說明,、項目結構和風險評估、業(yè)務功能說明書,、詳細設計說明書,、代碼實現(xiàn)、測試和安裝包等等,。一個項目的開發(fā)所需要的財力,、人力都是很多的，如果沒有一個好的遠景規(guī)劃,，對以后的開發(fā)進度會有很大的影響,，甚至會出現(xiàn)在預定時間內(nèi)不能完成項目或者完成的項目跟原來預想的不一樣。一份好的項目結構,、業(yè)務功能和詳細設計說明書對一個項目的開發(fā)有明確的指引作用,，它可以使開發(fā)人員對這個項目所要實現(xiàn)的功能在總體上有比較明確的認識，還能減少在開發(fā)過程中出現(xiàn)不必要的麻煩,。代碼的實現(xiàn)是一個項目開發(fā)成功與否的關鍵,，也就是說，前期作業(yè)都是為代碼的實現(xiàn)所做的準備,。

我深刻的認識到要成為一名優(yōu)秀的軟件開發(fā)人員不是一件容易的事情,，不僅要有足夠的干勁和熱情，還要有扎實的編寫代碼基礎,，必須要有事先對文檔進行可靠性報告,，功能說明書，詳細設計說明書等的編寫和一些風險評估的編寫的能力,。

除了圖書館,，最能讓我感覺到身在大學的就是實訓機房，在匆匆過去的兩個月內(nèi),，我往返于實訓機房與宿舍之間,，使我享受了一個充實的學習時期，讓我感受到了大學的魅力,，對自己充滿信心,，對大學充滿信心，以積極的心態(tài)迎接明天挑戰(zhàn),。

實訓中要求有扎實的理論基本知識,，操作起來才順心應手,，我這時才明白什么是“書到用時方恨少”。這就激發(fā)了學習的欲望,。

“學以致用”,，就是要把學來的知識能運用到實際操作當中，用實踐來檢驗知識的正確性,。我想,，這是實訓的最根本目的。

“紙上得來終覺淺,，絕知此事要躬行!”,在短暫的實訓過程中,，讓我深深感受到自己在實際運用中專業(yè)知識的匱乏。以前總以為自己學的還不錯,，一旦應用到實際就大不一樣了,，這時才真正領悟“學無止境”的含義。

經(jīng)過為期兩個月的電子政務服務平臺系統(tǒng)開發(fā)的實訓,，我對visual 軟件開發(fā)平臺有了更深一步的了解,，對微軟基礎類庫的認識與使用也有了大大的提高。以及如何使用sql server數(shù)據(jù)庫進行連接操作方面有了本質(zhì)的提高,。

短短的實訓結束了,，為我將來的就業(yè)打下了良好的基礎，也提高了我的軟件開發(fā)的水平,，今后我將會更加努力的學習,，不斷提高自身素質(zhì)，開拓創(chuàng)新,，與時俱進,，做一個優(yōu)秀的軟件開發(fā)工程師。

數(shù)據(jù)庫實訓心得體會篇二

關系型數(shù)據(jù)庫,，是指采用了關系模型來組織數(shù)據(jù)的數(shù)據(jù)庫。

博士首先提出的,，在之后的幾十年中，關系模型的概念得到了充分的發(fā)展并逐漸成為主流數(shù)據(jù)庫結構的主流模型,。

簡單來說,，關系模型指的就是二維表格模型,，而一個關系型數(shù)據(jù)庫就是由二維表及其之間的聯(lián)系所組成的一個數(shù)據(jù)組織。

關系模型中常用的概念：

關系：可以理解為一張二維表，每個關系都具有一個關系名,，就是通常說的表名

元組：可以理解為二維表中的一行,，在數(shù)據(jù)庫中經(jīng)常被稱為記錄

屬性：可以理解為二維表中的一列,，在數(shù)據(jù)庫中經(jīng)常被稱為字段

域：屬性的取值范圍,，也就是數(shù)據(jù)庫中某一列的取值限制

關鍵字：一組可以唯一標識元組的屬性，數(shù)據(jù)庫中常稱為主鍵，由一個或多個列組成

關系模式：指對關系的描述。其格式為：關系名(屬性1,，屬性2，...... ,，屬性n)，在數(shù)據(jù)庫中成為表結構

關系型數(shù)據(jù)庫的優(yōu)點：

容易理解：二維表結構是非常貼近邏輯世界的一個概念，關系模型相對網(wǎng)狀,、層次等其他模型來說更容易理解

使用方便：通用的sql語言使得操作關系型數(shù)據(jù)庫非常方便

易于維護：豐富的完整性(實體完整性,、參照完整性和用戶定義的完整性)大大減低了數(shù)據(jù)冗余和數(shù)據(jù)不一致的概率

數(shù)據(jù)庫實訓心得體會篇三

高并發(fā)讀寫需求

網(wǎng)站的用戶并發(fā)性非常高，往往達到每秒上萬次讀寫請求,，對于傳統(tǒng)關系型數(shù)據(jù)庫來說,，硬盤i/o是一個很大的瓶頸

海量數(shù)據(jù)的高效率讀寫

網(wǎng)站每天產(chǎn)生的數(shù)據(jù)量是巨大的，對于關系型數(shù)據(jù)庫來說,，在一張包含海量數(shù)據(jù)的表中查詢,，效率是非常低的

高擴展性和可用性

在基于web的結構當中，數(shù)據(jù)庫是最難進行橫向擴展的,，當一個應用系統(tǒng)的用戶量和訪問量與日俱增的時候,，數(shù)據(jù)庫卻沒有辦法像webserver和appserver那樣簡單的通過添加更多的硬件和服務節(jié)點來擴展性能和負載能力,。對于很多需要提供24小時不間斷服務的網(wǎng)站來說，對數(shù)據(jù)庫系統(tǒng)進行升級和擴展是非常痛苦的事情,，往往需要停機維護和數(shù)據(jù)遷移,。

對網(wǎng)站來說,，關系型數(shù)據(jù)庫的很多特性不再需要了：

事務一致性

關系型數(shù)據(jù)庫在對事物一致性的維護中有很大的開銷,，而現(xiàn)在很多web2.0系統(tǒng)對事物的讀寫一致性都不高

讀寫實時性

對關系數(shù)據(jù)庫來說，插入一條數(shù)據(jù)之后立刻查詢,，是肯定可以讀出這條數(shù)據(jù)的,，但是對于很多web應用來說,，并不要求這么高的實時性,，比如發(fā)一條消息之后，過幾秒乃至十幾秒之后才看到這條動態(tài)是完全可以接受的

復雜sql,，特別是多表關聯(lián)查詢

任何大數(shù)據(jù)量的web系統(tǒng)，都非常忌諱多個大表的關聯(lián)查詢,，以及復雜的數(shù)據(jù)分析類型的復雜sql報表查詢,，特別是sns類型的網(wǎng)站，從需求以及產(chǎn)品階級角度,，就避免了這種情況的產(chǎn)生,。往往更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢,，sql的功能極大的弱化了

在關系型數(shù)據(jù)庫中,，導致性能欠佳的最主要原因是多表的關聯(lián)查詢，以及復雜的數(shù)據(jù)分析類型的復雜sql報表查詢,。為了保證數(shù)據(jù)庫的acid特性,，我們必須盡量按照其要求的范式進行設計，關系型數(shù)據(jù)庫中的表都是存儲一個格式化的數(shù)據(jù)結構。每個元組字段的組成都是一樣,，即使不是每個元組都需要所有的字段,，但數(shù)據(jù)庫會為每個元組分配所有的字段，這樣的結構可以便于標語表之間進行鏈接等操作,，但從另一個角度來說它也是關系型數(shù)據(jù)庫性能瓶頸的一個因素,。

數(shù)據(jù)庫實訓心得體會篇四

持續(xù)一個月的數(shù)據(jù)庫實訓，讓我參與了軟件工程化的開發(fā)過程,。其中體會最深的便是我們這個實訓網(wǎng)的幾個之最：

一.項目最大：項目大是因為我們這個事業(yè)起點網(wǎng)站涉及到用戶眾多-高校,，企業(yè)，學生,，老師,，專家，第二個原因是網(wǎng)站的功能多-用戶管理,，網(wǎng)上實習,，網(wǎng)上競賽，畢業(yè)實習設計,，項目管理,，人才庫管理，人才推薦,，搜索 ... 項目大很容易造成系統(tǒng)范圍的泛濫,，在我們的開發(fā)初期，由于需求不太明確,，功能實現(xiàn)沒有重點,，造成了需求范圍的擴大，給項目開發(fā)進度造成了嚴重的滯后性,。然后我們召開了會議討論了這個問題,，一致認同先把項目的基本功能實現(xiàn)，將網(wǎng)站的基本架構搭建起來,，最后再在這個基礎上繼續(xù)增加我們網(wǎng)站的其他功能,。因此在這個過程中，我深刻體會到了軟件工程初期階段的需求分析以及概要設計的重要性,，這兩個文檔是指導我們后期開發(fā)的最重要的依據(jù),。

二.數(shù)據(jù)庫表最多：如此龐大的系統(tǒng)，就需要龐大的數(shù)據(jù)庫來支持,，所以項目大的直接后果就是我們的數(shù)據(jù)庫表特別多,，而且表與表之間的依賴關系也復雜，實體類之間的關系眾多,，設計起來有一定的難度,。數(shù)據(jù)庫的另外一個問題是-數(shù)據(jù)表的屬性,，數(shù)據(jù)表屬性的設計完全是依賴于我們剛開始做的需求分析文檔，如果需求分析不完整的話,，就會造成數(shù)據(jù)庫表屬性的缺失,，從用戶的角度看，就會覺得你的系統(tǒng)提供的數(shù)據(jù)不夠全面,，信息量小,。

三.開發(fā)團隊最大：我們團隊一共有十四個人，這個對于我們的項目經(jīng)理來說,，是一個相當嚴峻的問題,，畢竟十四個人的團隊相當于其他幾個小組加起來的人數(shù)總和，管理起來有相當大的難度,。對于我們這些小組成員來說,，由于溝通渠道太多，造成了我們項目中遇到問題,，不知道去跟哪個小組成員溝通,。為了解決這個問題，我們在團隊中又選出了三個小組長,，小組成員遇到問題,，先去咨詢小組長，然后小組長提供反饋信息,。

四.項目各個模塊間藕合度高：網(wǎng)站涉及的各個功能模塊之間的聯(lián)系緊密,，模塊之間的接口設計的好壞是項目最終集成成功與否的最重要因素。用戶管理這一個部分要為每個模塊提供接口,，主要是用戶的編號以及用戶的類型等,。每個頁面之間的鏈接也是其中重要的模塊接口。這個問題由于我們前期做好了充分的溝通以及按照概要設計中的接口說明去設計自己的模塊,，所以后期的模塊整合沒有遇到什么太大的不兼容性等問題,。

接下來就談談我這一個月中的工作：

需求分析階段：需求分析階段我完成了網(wǎng)上競賽模塊的需求分析，其中遇到的主要問題是閱讀材料后發(fā)現(xiàn)網(wǎng)上實習,，網(wǎng)上競賽,，畢業(yè)設計指導這幾個模塊的功能是類似的，提取需求分析后不夠明確,，經(jīng)過幾次跟湯老師的交流后，確定了這幾個模塊之間的具體差別,，網(wǎng)上競賽模塊的基本需求也大致確定了,，網(wǎng)上競賽模塊的基本功能就是學生通過網(wǎng)站報名參加競賽，企業(yè)審核通過后,，專家對作品進行評分,，排名,。

概要設計階段：在需求分析的基礎上，對網(wǎng)上競賽模塊進行了比較具體的概要設計,，流程圖(ipo圖以及用例圖);這個階段的主要難點是對網(wǎng)上競賽業(yè)務流程的描述,，如何實現(xiàn)學生報名，企業(yè)發(fā)布,，專家評審的步驟操作,，與及跟其他模塊對該模塊的限制。

數(shù)據(jù)庫設計階段：我負責整合初步數(shù)據(jù)庫設計說明書,，分配組員按照各自的功能模塊的具體需求設計自己模塊需要的數(shù)據(jù)表,，然后對這些數(shù)據(jù)表進行整合。在這個過程中遇到的問題就是數(shù)據(jù)庫實在是太大了,，最后下來一共有30多張表,，表與表之間的關系復雜，關聯(lián)性大,，需要設置的外鍵較多,，很難將所有的屬性字段給提取出來，屬性的類型設置也是一個問題,，采用數(shù)值型還是采用字符串性在數(shù)據(jù)庫設計中尤為重要,，因為在后臺搜索方面，數(shù)值型比較快捷,，而在數(shù)據(jù)顯示方面,，字符串型又有直接讀出不用轉(zhuǎn)換的好處。每個表的主鍵我們采用了用實體的編號去標記它,，因為這樣實體間關聯(lián)起來會更加簡單,。數(shù)據(jù)庫的設計關鍵是要對整個項目的整體的把握，并且要細化對每個實體類的具體屬性要求,。

詳細設計階段：我覺得是最重要的一個方面,，一個完整的詳細設計說明應該可以幫助程序員完成具體的實現(xiàn)，程序員可以不用考慮模塊之間的耦合問題,，只需要將單一的功能按照邏輯順序編寫出來就可以了,。網(wǎng)站整體構架搭好了，我們就可以在里面填充自己的功能了,。但是因為時間太倉促了,，我們這個階段也就縮水了，帶來后面的問題就是后期代碼編寫的時候比較混亂,，函數(shù)接口較難統(tǒng),，界面風格多樣化。這個階段,，我的主要工作是跟隊友一起設計出了網(wǎng)上競賽模塊的學生,，企業(yè),，管理員，高校以及專家的界面,。

編碼階段：開發(fā)的,，主要任務就是從工具中選出你想要的控件，然后在控件響應函數(shù)中填充代碼,，完成相應的事件響應,。這里遇到的最大問題是頁面的排版問題，因為自己是第一次開發(fā)網(wǎng)站,，造成了自己設計的界面風格單調(diào),，不太美觀，現(xiàn)在就盡量做到頁面的整齊,。這個階段主要做的就是：寫代碼→編譯→調(diào)試→寫代碼,。

這一個月中我學到了很多東西，編寫網(wǎng)站,，最重要的是讓我經(jīng)歷了軟件工程化的所有階段,，讓我對整個軟件工程有了感性的認識，而且將大學三年所學到的知識進行了一次系統(tǒng)的串聯(lián),，更重要的是學會了如何跟項目團隊中的成員溝通問題,，這是一個寶貴的實踐經(jīng)驗。