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