數據庫實訓心得體會

數據庫是什麼？在的研究與開發中，管理器的作用十分顯著。一個實用的商品化的管理系統，除了它本身在功能、性能上的優勢外，還必須提供功能強大、使用方便的管理工具。下面是本站帶來的數據庫實訓心得體會，希望可以幫到大家。

數據庫實訓心得體會篇一

一個月的數據庫實訓就轉眼間就上完了，期間講解了一個學生管理系統，最後還做了一個小的數據庫鏈接作業。現在就説説關於vb鏈接的數據庫的一些方法。

首先説數據庫，簡單的説就是建表格,然後把一張一張的表格和在一起,成為一大堆的數據集合。他是依照某種數據結構組織起來並存放二級存儲器中的數據集合，基本分為三個層次，物理數據層，概念數據層和邏輯數據層。不同層次間的聯繫是通過映射來轉換的。

大多數vb鏈接數據庫都使用ado控件，他可以分為分為有源數據庫和無源數據庫，即是否使用了dsn數據源。在連接數據庫前首先要在vb菜單中“工程”-“引用”或“部件”從中選擇 microsoft activex data objects 2.6 library和 microsoft activex data objects recordset 2.6兩個組件，然後定義鏈接的對象，用什麼名字由自己決定。這樣數據庫也就基本上鍊接好了。

數據庫實訓心得體會篇二

3月7號進入宏天實訓公司參加軟件開發實訓的，在此次實訓中，除了讓我明白工作中需要能力，素質，知識之外，更重要的是學會了如何去完成一個任務，懂得了享受工作。當遇到問題，冷靜，想辦法一點一點的排除障礙，到最後獲取成功，一種自信心就由然而生，這應該就是工作的樂趣。有時候不懂的就需要問別人了，虛心請教，從別人的身上真的能學到自己沒有的東西，每一次的挫折都會使我更接近成功。還有學會了在工作中與人的合作與交流，同樂同累，合作互助，這是團體的精神，也是必須學習的東西。

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

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

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

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

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

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

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

經過為期兩個月的電子政務服務平台系統開發的實訓，我對Visual 軟件開發平台有了更深一步的瞭解，對微軟基礎類庫的認識與使用也有了大大的提高。以及如何使用SQL Server數據庫進行連接操作方面有了本質的提高。

短短的實訓結束了，為我將來的就業打下了良好的基礎，也提高了我的軟件開發的水平，今後我將會更加努力的學習，不斷提高自身素質，開拓創新，與時俱進，做一個優秀的軟件開發工程師。

數據庫實訓心得體會篇三

持續一個月的數據庫實訓，讓我參與了軟件工程化的開發過程。其中體會最深的便是我們這個實訓網的幾個之最：

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

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

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

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

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

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

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

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

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

編碼階段：我們是用開發的，主要任務就是從工具中選出你想要的控件，然後在控件響應函數中填充代碼，完成相應的事件響應。這裏遇到的最大問題是頁面的排版問題，因為自己是第一次開發網站，造成了自己設計的界面風格單調，不太美觀，現在就儘量做到頁面的整齊。這個階段主要做的就是：寫代碼→編譯→調試→寫代碼。

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

數據庫實訓心得體會篇四

關係型數據庫，是指採用了關係模型來組織數據的數據庫。

關係模型是在1970年由IBM的研究員博士首先提出的，在之後的幾十年中，關係模型的概念得到了充分的發展並逐漸成為主流數據庫結構的主流模型。

簡單來説，關係模型指的就是二維表格模型，而一個關係型數據庫就是由二維表及其之間的聯繫所組成的一個數據組織。

關係模型中常用的概念：

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

元組：可以理解為二維表中的一行，在數據庫中經常被稱為記錄

屬性：可以理解為二維表中的一列，在數據庫中經常被稱為字段

域：屬性的取值範圍，也就是數據庫中某一列的取值限制

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

關係模式：指對關係的描述。其格式為：關係名(屬性1，屬性2，...... ，屬性N)，在數據庫中成為表結構

關係型數據庫的優點：

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

使用方便：通用的SQL語言使得操作關係型數據庫非常方便

易於維護：豐富的完整性(實體完整性、參照完整性和用户定義的完整性)大大減低了數據宂餘和數據不一致的概率

數據庫實訓心得體會篇五

高併發讀寫需求

網站的用户併發性非常高，往往達到每秒上萬次讀寫請求，對於傳統關係型數據庫來説，硬盤I/O是一個很大的瓶頸

海量數據的高效率讀寫

網站每天產生的數據量是巨大的，對於關係型數據庫來説，在一張包含海量數據的表中查詢，效率是非常低的

高擴展性和可用性

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

對網站來説，關係型數據庫的很多特性不再需要了：

事務一致性

關係型數據庫在對事物一致性的維護中有很大的開銷，而現在很多web2.0系統對事物的讀寫一致性都不高

讀寫實時性

對關係數據庫來説，插入一條數據之後立刻查詢，是肯定可以讀出這條數據的，但是對於很多web應用來説，並不要求這麼高的實時性，比如發一條消息之後，過幾秒乃至十幾秒之後才看到這條動態是完全可以接受的

複雜SQL，特別是多表關聯查詢

任何大數據量的web系統，都非常忌諱多個大表的關聯查詢，以及複雜的數據分析類型的複雜SQL報表查詢，特別是SNS類型的網站，從需求以及產品階級角度，就避免了這種情況的產生。往往更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能極大的弱化了

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

數據庫實訓心得體會篇六

(1)數據(Data)

數據就是對客觀事物反映的一種物理符號，可以是數字、文字、圖形、圖像、聲音、語言和視頻等。這些多種形式的數據都需經過數字化後才能存入計算機。 –符號

(2)數據處理(Data Processing)

數據處理是指對各種形式的數據進行收集、整理、存儲、分類、排序、檢索、加工、統計和傳輸等一系列活動的總和。

(3)數據庫(DataBase，DB)

數據庫是長期存儲在計算機設備上結構化的、可共享的相關數據的集合。它不僅包括描述事物的數據本身，而且還包括相關事物之間的聯繫。 –集合

(4)數據庫系統(DataBase System，DBS)

數據庫系統是指計算機系統引入數據庫後，利用數據庫技術進行數據管理的計算機系統。他一般由數據庫、數據庫管理系統(及開發工具)、應用系統、數據庫管理員(DataBase Administrator，DBA)和用户構成。在不引起混淆的情況下人們常常把數據庫系統簡稱為數據庫。

(5)數據庫管理系統(DataBase Management System，DBMS)

數據庫管理系統是一個介於用户和操作系統之間的一層數據管理軟件，是數據庫系統中的一個重要組成部分，可以幫助用户建立、使用和維護數據庫。目前廣泛使用的大型數據庫管理系統有Oracle、Sybase等，小型數據庫管理系統有SQLserver、VisualFoxPro、Access等。