vb.net机房收费系统重构——总结（一）梳理业务与表结构，vb.net收费系统

       机房收费系统已经进行了一段时间，前两天收到通知，要抽查机房重构，而我也成为其中之一。所以虽然机房验收过了，又再次重新自己检验，调试，整体文档的过程。经过师父一番指导，收获颇多。对机房重构有了进一步的认识。

（一）再次梳理业务：结账

机房收费系统中，管理员有项结账功能，目的是为操作员结账结账内容如图

        其中有售卡张数，退卡张数，收入金额等，而没有消费金额。

        这是因为操作员只是一个负责收入支出的“管家”,而真正的学校收入是学生消费的那部分。

        举个例子：你办理了一张卡，并在里面充值了100元，消费了20元之后就退卡了，退给了你80元,那么学校的真正收入就是那20元。而操作员只是负责这个过程，只是负责操作罢了，所以他和学生消费多少是没有关系的。

所以在日结账单和周结账单中就有消费金额这一项

          在这个表中，消费金额才是学校真正的收入，而充值金额虽然多，但学生可能随时可以退卡。这部分并不是学校的真正收入。

理清了这一部分，所以操作员中结账按钮和日结账单和周结账单并不挂钩。

（二）表结构

         我的机房收费中，将卡表和学生表合并到一张表里面。如图

        很明显，如果按实体关系，卡应该是一张表，学生应该是一张表。这样看起来才更符合三范式。而很多人将三范式视为“不死法宝”，认为这样提高了数据的简洁性，可维护性。因此在这个系统中也是严格按照三范式。虽然并没有什么错，但我认为在实际应用中还是要从实际业务出发，也就是具体业务具体分析。

       严格的E-R图中，所有实体关系应该是一对多的，不存在多对多，如果这样就要再抽出一张表。而一对一的关系也完全可以放到一张表中，因为一个学生严格的对应一张卡，反之亦然。而且学生表字段和卡表字段并不是非常多，放到一张表并不会造成数据量太大的问题。

       放到一张表，我完全可以只操作一张表就可以操作所有信息，避免了容易修改学生信息的同时，忘接了修改卡表，造成信息不对称的结果。操作效率也大大提高。

    通过这次师父讲解，我认为在实际的系统设计中，我们应该多思考一下，是不是要采用“第三范式”，不要再盲目追捧。