這次的機房收費數據庫在重建的時候時候將之前的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搭建橋梁，這樣設計很像“橋接模式”中的設計思想，讓卡和學生之間更加靈活而不是被綁在一起。
