vb.net機房收費系統重構——總結（一）梳理業務與表結構，vb.net收費系統

vb.net機房收費系統重構——總結（一）梳理業務與表結構，vb.net收費系統

       機房收費系統已經進行了一段時間，前兩天收到通知，要抽查機房重構，而我也成為其中之一。所以雖然機房驗收過了，又再次重新自己檢驗，調試，整體文檔的過程。經過師父一番指導，收穫頗多。對機房重構有了進一步的認識。

（一）再次梳理業務：結賬

機房收費系統中，管理員有項結賬功能，目的是為操作員結賬結賬內容

        其中有售卡張數，退卡張數，收入金額等，而沒有消費金額。

        這是因為操作員只是一個負責收入支出的“管家”,而真正的學校收入是學生消費的那部分。

        舉個例子：你辦理了一張卡，並在裡面充值了100元，消費了20元之後就退卡了，退給了你80元,那麼學校的真正收入就是那20元。而操作員只是負責這個過程，只是負責操作罷了，所以他和學生消費多少是沒有關係的。

所以在日結賬單和周結賬單中就有消費金額這一項

          在這個表中，消費金額才是學校真正的收入，而充值金額雖然多，但學生可能隨時可以退卡。這部分並不是學校的真正收入。

理清了這一部分，所以操作員中結賬按鈕和日結賬單和周結賬單並不掛鈎。

（二）表結構

         我的機房收費中，將卡表和學生表合并到一張表裡面。

        很明顯，如果按實體關聯，卡應該是一張表，學生應該是一張表。這樣看起來才更符合三範式。而很多人將三範式視為“不死法寶”，認為這樣提高了資料的簡潔性，可維護性。因此在這個系統中也是嚴格按照三範式。雖然並沒有什麼錯，但我認為在實際應用中還是要從實際業務出發，也就是具體業務具體分析。

       嚴格的E-R圖中，所有實體關聯應該是一對多的，不存在多對多，如果這樣就要再抽出一張表。而一對一的關係也完全可以放到一張表中，因為一個學生嚴格的對應一張卡，反之亦然。而且學生表欄位和卡表欄位並不是非常多，放到一張表並不會造成資料量太大的問題。

       放到一張表，我完全可以只操作一張表就可以操作所有資訊，避免了容易修改學生資訊的同時，忘接了修改卡表，造成資訊不對稱的結果。操作效率也大大提高。

    通過這次師父講解，我認為在實際的系統設計中，我們應該多思考一下，是不是要採用“第三範式”，不要再盲目追捧。