机房收费系统已经进行了一段时间,前两天收到通知,要抽查机房重构,而我也成为其中之一。所以虽然机房验收过了,又再次重新自己检验,调试,整体文档的过程。经过师父一番指导,收获颇多。对机房重构有了进一步的认识。
(一)再次梳理业务:结账
机房收费系统中,管理员有项结账功能,目的是为操作员结账结账内容如图
其中有售卡张数,退卡张数,收入金额等,而没有消费金额。
这是因为操作员只是一个负责收入支出的“管家”,而真正的学校收入是学生消费的那部分。
举个例子:你办理了一张卡,并在里面充值了100元,消费了20元之后就退卡了,退给了你80元,那么学校的真正收入就是那20元。而操作员只是负责这个过程,只是负责操作罢了,所以他和学生消费多少是没有关系的。
所以在日结账单和周结账单中就有消费金额这一项
在这个表中,消费金额才是学校真正的收入,而充值金额虽然多,但学生可能随时可以退卡。这部分并不是学校的真正收入。
理清了这一部分,所以操作员中结账按钮和日结账单和周结账单并不挂钩。
(二)表结构
我的机房收费中,将卡表和学生表合并到一张表里面。如图
很明显,如果按实体关系,卡应该是一张表,学生应该是一张表。这样看起来才更符合三范式。而很多人将三范式视为“不死法宝”,认为这样提高了数据的简洁性,可维护性。因此在这个系统中也是严格按照三范式。虽然并没有什么错,但我认为在实际应用中还是要从实际业务出发,也就是具体业务具体分析。
严格的E-R图中,所有实体关系应该是一对多的,不存在多对多,如果这样就要再抽出一张表。而一对一的关系也完全可以放到一张表中,因为一个学生严格的对应一张卡,反之亦然。而且学生表字段和卡表字段并不是非常多,放到一张表并不会造成数据量太大的问题。
放到一张表,我完全可以只操作一张表就可以操作所有信息,避免了容易修改学生信息的同时,忘接了修改卡表,造成信息不对称的结果。操作效率也大大提高。
通过这次师父讲解,我认为在实际的系统设计中,我们应该多思考一下,是不是要采用“第三范式”,不要再盲目追捧。