數據庫課程設計心得體會1000字

　　【篇1】

在開學的第一週，我參加了院裏組織的數據庫課程設計，這項任務是分組分工完成的，我們組有五名成員，分別是我們班學號的後五位同學，很榮幸地我被推薦爲我們組的組長，在組長的“英明”指導下，全體組員團結奮鬥，使得任務完成地比我們預期的要稍早一些，也比預期要漂亮一些，這一點我們都感到很高興也很自豪。

王婆賣瓜時間過了，言歸正傳吧。凡是都要有個總結，以下便是我在這個課程設計中的一點心得。

首先我分析一下我們組任務順利完成的成功之處並總結一些經驗，供以後反省參考用。

凡事預則備，不預則廢。這是我的座右銘，也是我深有感悟的幾句古語之一。在這個項目的開始階段，老師便讓我們做了個進度安排表，我很好的利用了這次機會，花了較多心思作出了一個很詳細的進度安排表，之後我們組任務的完成也是嚴格按照這個進度表進行的。當然我後來去了解了一下別的組的情況，有些組的進度安排表沒我們組做完善的一個很重要的原因就是他們對這一週的數據庫課程設計到底還沒什麼概念。導致這種現象的原因有很多方面，一個是基礎太差不能理解老師安排的任務(當然這種人比較少)，一種是缺乏交流，這個交流包括組內的交流，也包括組間的，更包括與老師之間的，這也就引出了我的第二個心得。

多交流，這是我這次項目的第二個心得。對於這種分工完成的項目，組員之間的交流是極其必要的。如果組員之間不能很好的溝通，不僅會做很多無用功，而且也會做很多重複的工作。組員之間很好點，我們每天都會在qq上或者見面相互交流，並及時修改進度安排表;除此之外，我們還相互幫助解決問題，或者共同解決問題，比如說這次的概念模型的設計，我們組負責設計概念數據模型的同學(趙##)和負責數據需求分析的同學(左##)就經常溝通(因爲兩者的任務聯繫比較緊密)，共同解決問題，纔會做出令我們組員都比較滿意的數據概念模型和漂亮的數據需求分析文檔;當然最重要的是我們也常會去與老師溝通，老師也在關鍵的設計地方也給了很多很多的寶貴意見。當然不得不作出檢討的地方是組長這次與老師交流的比較少，反而不及組員，希望在接下來的項目中能有所改觀，起好帶頭作用。我同樣也有觀察別的組完成情況，發現有些組出現了組長包乾或者組長與個別組員的包乾的現象，我覺得導致出現這種可怕現象的主要責任在於組長，組長的任務不僅僅參與部分任務的完成，更重要的是分配任務並協調組間關係，是溝通交流的一根主要管道。通俗的講就是組長上要聯繫老師，中要與他組交流，下要與組員積極溝通，我覺得這也是組長這個角色的設置的必要所在吧。我真心地希望在我們下一個創新課程j2ee的訓練中我們班不要再出現這種現象，每個人都有平等得到鍛鍊的機會，組長不認真分配任務不積極與組員溝通在某種程度上剝奪了組員得到鍛鍊的機會，而更可悲的是很多組員還沒有意識到這一點。

多主動，這一點原本和上一點多交流有很多相似之處，但我把它專門列出來也是爲了體現他的重要性。多主動一方面是說要主動積極的思考解決問題。有很多同學比較好學，總是不停的在與別人溝通交流，看似很積極，但是仔細分析他提出的那些問題着實汗涔涔，有些問題近似牢騷話類，稍微開動點腦筋就能解決的，但其總不會先去尋找解決問題的辦法後再提出個經過大腦過濾的問題，說白了就是凡事都沒有個自己稍微成熟的看法。關於這一點我曾經就一度犯過，現在回想起那段歲月着實還是對有些同學的耐心感動到熱淚盈眶。直到有一天張老師找我談了一次我才幡然醒悟到，之後便有了教大的長進，至少變得比較會提問題了。當然我覺得這一點還是值得給與一定程度的肯定的，至少他肯學，比起那種喜歡“搭順風車”的同學強多了。我上面提到的而關於組長的剝奪組員鍛鍊權利的問題想必要是被有些組長看了會大有意見，組長會說：“你以爲我喜歡一個人全乾啊，還不是被逼的”。出現這種情況也於他們組喜歡“搭便車”的人太多了有關係，這也在一定程度上映射出了這個組組員和組長團隊意識的極度缺乏。又扯遠了，總之喜歡“搭車”的那部分同學可要提高警惕了，眼看過一年就要出去實習了，還不抓緊時間主動學點東西，還不停的讓組長剝削你得到鍛鍊的機會，以後在這條路上怎麼混得下去啊?

　　【篇2】

由於平時接觸的都是一些私人項目，這些項目大都是一些類庫，其他人的交流相對可以忽略不計，因此也就不考慮規範化的文檔。實際上從學習的經歷來看，我們接觸的知識體系都是屬於比較老或比較傳統的，與現在發展迅速的IT行業相比很多情況已不再適用，尤其是當開源模式逐漸走近開發者後更是如此。

雖然這次是一個數據庫課程設計，由於本人在選擇項目的時候是本着對自己有實際應用價值的角度考慮的，所以其中也涉及到一些數據庫以外的設計。對於OOA/OOD的開發模式有時不免要提出一些疑問，UML是設計階段的工具，而它基本涵蓋了軟件設計的方方面面，也就是說按照這一軟件工程的正常流程，在動手寫第一句代碼之前，開發人員已經非常熟悉軟件產品了，這對於相當有經驗的架構師一類人說可能會很容易，但是我們作爲學生，連足夠的編碼經驗都沒有，卻首先被教授並要求先OOA再OOP，這樣直接導致的問題就是文檔與編碼對不上號，在修改代碼的時候基本不會再去審查文檔和先前的分析。甚至根本就是現有代碼再有文檔，即便是這種情況，代碼與文檔還是不對應。不可否認，在傳統軟件工程的詳細設計之前的項目過程中還是有很多利於項目開發的部分的。所以我就一直在尋找適合我——針對探究型項目——的開發模式，這次的項目也算是一次嘗試，當然這個過程並不會太短。

回到數據庫設計上了，這次的數據庫設計我是嚴格按照數據庫建模的步驟來進行的，老實說我並沒有感覺這樣的流程對開發帶來多大的幫助，反倒是覺得將思維轉化爲圖表很浪費時間。總體上來說這次的項目也不是很大，而且在數據庫的設計上比較保守，也就是說實際上數據庫設計還可以再完善完善的。隨着我對計算機領域的拓寬和加深，我也會靜下心來思考在接觸計算機之前的行爲，很多次我能深切感覺到，其實我的大腦(未於別人比較)本身就是在使用一種更接近關係數據庫的方式來記憶，所以我很可恨自然的設計出符合三範式的表結構來，即便我不知道這些範式的確切含義。可能就像“範式不太容易用通俗易懂的方式解釋”一樣，在“讓工具用圖標表述我的思維”時費了一番力氣。

從我作爲項目的提出人和實現者來看，這是個失敗的項目，結合幾次教學項目的的實踐，發現這也已經不是第一次了。主觀原因佔多數，比如，嘗試新的開發方式，根據設計花了太多的時間來抽象出公用的庫而忽略業務邏輯。就這次項目而言，失敗的原因有以下幾點：

使用了新的開發環境(Vim)，這是首次在脫離高級IDE的情況下編碼。

使用了新的開發語言(Python，Actionscript3)，因爲我一直比較喜歡“學以致用”，而且這樣的“數據驅動型”軟件的整套自實現的庫都已經完成了，但是由於語言本身的差異，遷移時問題很多，當發現這一點是，已沒有多少有效剩餘時間了。

編碼流程的不妥，我比較喜歡從底層的庫開始開發，因爲一旦庫測試通過，將很容易將它放到不同的表示層下。但如果庫沒有測試成功，將導致整個項目沒有任何可視化模型，所以這次的項目無法提交“可運行的代碼”。

實踐目的的不同，我輕易不放棄鍛鍊的機會，事實上，有機會就一定要比以前有所突破，總是照搬以前的做法還不如就不做呢。這個前提是因爲現在能完全用來的學習的時間比較多，等到工作時再這樣做的可能性就很小了，因此當然要抓緊機會了。不過還有一個隱藏原因，總以爲自己很了不起，其實“遇到的問題數跟人的能力是成正比的”。