成長軌跡 資料庫課程設計總結

2021-08-22 17:12:06 字數 1540 閱讀 6504

這個本該是在專案完成之後才寫的,但是因為一些主客觀原因,本專案還沒有實現完成,因此沒有「可執行的**」。

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

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

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

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

使用了新的開發環境(vim),這是首次在脫離高階ide的情況下編碼。

使用了新的開發語言(python,actionscript3),因為我一直比較喜歡「學以致用」,而且這樣的「資料驅動型」軟體的整套自實現的庫都已經完成了,但是由於語言本身的差異,遷移時問題很多,當發現這一點是,已沒有多少有效剩餘時間了。

編碼流程的不妥,我比較喜歡從底層的庫開始開發,因為一旦庫測試通過,將很容易將它放到不同的表示層下。但如果庫沒有測試成功,將導致整個專案沒有任何視覺化模型,所以這次的專案無法提交「可執行的**」。

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

客觀原因在這裡就不說了。

由於專案還未完成,暫時無法提出需要改進了地方。

資料庫課程設計

資料庫課程設計 設計目的 1 回顧關聯式資料庫的理論知識,理論聯絡實際,解決實際問題 2 通過分析問題和輔助開發工具的應用,掌握在ms sql server或oracle平台進行資料庫實現 3 嘗試結合高階語言程式設計實現資料庫管理與應用系統的開發 時間安排 1 集中指導 14學時左右 2 課外學時...

資料庫課程設計

要求b s結構,前台語言框架不限,後台資料庫不限建議 sql server mysql 機時安排系統 建立乙個機時安排系統,編寫應用程式完成系統開發。建立基本表 機房安排表 周節,星期,節號,機房號,教師,課程名,班級,人數 基於win10作業系統,資料庫使用mysql,web編寫使用php。版本 ...

資料庫課程設計

一.概述 學生資訊管理系統是學校管理的重要工具,是學校不可或缺的一部分。隨著在校人數的不斷增加,教務系統的數量也不斷的 學校工作繁雜,資料眾多,人工管理資訊的難度也越來越大,顯然是不能滿足實際的需要,效率也是很低的。並且這種傳統的方式存在著眾多的弊端,如 保密性差.查詢不便.效率低,很難維護和更新等...