機房重構---為什麼要把卡表和學生表分開,重構---

來源:互聯網
上載者:User

機房重構---為什麼要把卡表和學生表分開,重構---

    這次的機房收費資料庫在重建的時候時候將之前的Studetn_Info分為了Card_Info和Student_Info,淺顯的知道是為了給學生和卡之間解耦合,但是究竟應該在表單和代碼上如何設計才能把種思想體現出來,直到我開始敲“註冊學生資訊”的時候才有了自己的見解。(歡迎和大家一起交流思想。)

    首先,:


        這個頁面和之前舊版本系統那個頁面一樣,在編寫代碼的時候,會發現當單擊“存檔”時,對兩個表 Student_Info 和 Card_Info中添加記錄的時候“學生”和“卡”還是被“捆綁”在一起的,即添加一個新的卡不管是否能夠對應多個學神,或者是否已存在學生資訊,都是需要重新再寫一次學生的相關資訊的(類似於“系別”、“班級”……),於是回頭看自己的資料庫圖表如下:


    我想如果介面不改變的話,它更應該對應的是之前學生和卡不分為兩張表的情況,而我這次的設計理念應該是:先添加“學生資訊”,然後添加“卡資訊”,在添加卡資訊的時候通過選擇或者輸入“學號”來實現卡表和學生表之間的對應(Card_Info中StudentNo為外鍵,建立兩張表的聯絡),這樣就實現了“卡表”和“學生表”的解耦和,就像上面資料庫圖表中,在添加卡的時候是通過Foreign Key來實現二者的關聯。

    先看看相應介面:

    註冊學生資訊:


    註冊卡資訊:


   下面具體分析為什麼把註冊分為“註冊學生資訊”和“註冊卡資訊”

  (1)為了更好的在介面和代碼中體現了資料庫中“卡表”和“學生表”的分離。

    開始沒有將其分為兩個介面的時候敲註冊學生資訊的代碼很費勁,可以說關係比較亂,對應的主外鍵理不清,感覺資料庫雖然設定成了兩張表,但是寫起代碼來還沒有之前一條代碼方便,甚至考慮的東西要更多,兩張表的耦合更強了。

 

  (2)避免了之前“卡”和“學生”捆綁在一起進行註冊的現象,如果一人對應多卡,在添加卡的時候就通過選擇學號來綁定學生資訊,而不是再次重複的輸入。

 

  (3)當退卡的時候,在已經結賬的情況下,將卡表中資訊備份到“CancelCard”表之後刪除“Card_Info”表中對應d的卡資訊,同時保留學生表中相應學生資訊,再次添加卡或者啟用這張卡的時候直接輸入之前的學號就實現再次綁定而不是重新輸入學生整體的資訊。(即學生資訊是死的,通過註冊、退卡來與其建立聯絡)

 

    綜上所述,註冊資訊的時候分為兩個表單來註冊,註冊卡資訊對應卡表,註冊學生對應學生表,二者通過Card_Info表中Foreign Key搭建橋樑,這樣設計很像“橋接模式”中的設計思想,讓卡和學生之間更加靈活而不是被綁在一起。

 

    下一篇部落格將對“註冊、充值、退卡”的思路進行梳理和最佳化,這樣設計的思想在其中的體現會讓My Code邏輯更清晰和簡單。

   That is all.


相關文章

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.