机房重构---为什么要把卡表和学生表分开

本文主要是介绍机房重构---为什么要把卡表和学生表分开，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

    这次的机房收费数据库在重建的时候时候将之前的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搭建桥梁，这样设计很像“桥接模式”中的设计思想，让卡和学生之间更加灵活而不是被绑在一起。

 

    下一篇博客将对“注册、充值、退卡”的思路进行梳理和优化，这样设计的思想在其中的体现会让我的代码逻辑更清晰和简单。

   That is all.

这篇关于机房重构---为什么要把卡表和学生表分开的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---