图书馆维护系统 感受

       图书馆维护系统已经做了半个多月了，还没开工的时候，四个人讨论着需求，觉得

太简单了吧也。需求大概也就讨论了一个上午吧，然后贾琳师哥就开始给我们四个分配

任务了。

       例如，学习PowerDesiner—设计数据库、学习动软——将数据库导出代码（可以导

出三层架构模式、抽象工厂模式…）、修改社河他们人事管理系统的那个主界面，做成

图书馆的。

        这些东西都很简单，像powerDesiner、动软也就是一些工具，主界面也不用做，直

接小改一下就可以用啦。

       前面进行的都还挺顺利的，后来问题就来了。

        不知道是高估了自己的能力，还是太小瞧了这个系统。贾琳师哥让我设计数据库，

好吧，我按照需求设计好了数据库，让他们三个看了一下，觉得也还ok。但是，结果真

不是那么回事。到现在都觉得坑的最惨的是我。

真正理解了什么是“业务为王”，业务没搞清楚，设计出来的数据库也是不合理的。

我们的系统分了三个权限：管理员、组长、组员；五个模块：人员管理、机器管理、值

班教师管理、问题管理、任务管理

        我负责“任务管理”模块，做起来才发现不是那么回事，任务管理是该系统的核心部

分，包括着管理员：添加任务、分配任务、查看任务（查看所有任务、查看小组任

务）、查看维修日志….

组长：查看任务、分配任务、审批任务、查看审批记录、查看维修日志…

组员：查看任务、提交任务、查看维修日志…

最初没考虑太多，就淡淡的分析了一下，建好数据库，就剩敲代码了。但是做起来…呵

呵

我建立的数据库：

T_MemberInfo(成员信息表)、T_GroupInfo（小组信息）、T_ComputerInfo（机器信息

表）、

T_TaskInfo（任务信息表）、T_AssignTask（任务分配信息表）、

T_CommomSoftwareInfo（常用软件信息表）、T_CommonPwdInfo（常用密码信息

表）、T_ProblemType（问题类型信息表）、

T_ProblemTypeInfo（问题信息表）、T_SubmitInfo（提交任务信息表）、

T_ApproveInfo（审批信息表）、T_DutyTeacherInfo（值班教师信息表）、

T_MaintainRecordInfo（维护记录信息表）

 

知道我当初做时，它的难点吗？

1，管理员和组长都有分配任务的权利，但是不同的是管理员给组长分配任务、组长给

组员分配任务。数据库里怎么存储这些分配信息？

2，提交任务后审批不通过，数据库如何显示？下次查看任务时，此任务该如何显示？

3，查看维护日志是不是直接可以从数据库中查询，不需要维护日志表？

…..现在看来这些问题已不是问题了，只要当时把业务屡清楚，数据库设计好，是没有

问题的。但是最初因为数据库设计不是很好，后来因为业务需求的再次分析，再加上不

能动改数据库，我就开始边研究数据库、边研究业务，像提交任务信息表是后来加上去

的，而且还在其他表里加了很多字段，来满足业务需求。

   这半个月做的我真的是很狰狞啊，导致这个后果的原因我分析了一下：

1，最初没有分析好需求

2，需求没分析好，直接导致数据库的设计不合理

3，数据库的设计不合理，导致真正着手做时，细研究需求时就发现不能满足

4，考虑问题太简单，觉得应该是这样，真正做起来 其实是那样

 

总结：1，虽说做事要把控全局观，但是对于系统业务来说，先要把控全局，然后还是

必须要从业务的不同方面精准研究；

2，不能小看任何一个 哪怕自己觉得不是很大的系统，每个系统都有它的强大之处

3，系统都是越做越大的，今天添个A功能，明天加个B功能。

4，做一个功能齐全又操作简单，让客户满意的系统不容易

 

加油吧！！Come On同志们！！