这是一次比较完整的团队合作项目，它要求团队各成员对系统的主体设计搭成一定的共识，这包括数据库设计，需求分析，以及其它一些细节，因此在编码之前的准备工作一定要充分。

　　在设计之前，我们两组对于数据库的设计进行了激烈的讨论，最后在一些关键的问题上统一了意见。

　　接下来的工作便是需求分析，具体结构设计，并制订小组项目详细计划，项目的进行将严格按照所制订的计划执行。

　　然后小组成员对各自的数据库进行了设计，并且以数据字典的形式进行了共享。

　　企业级人力资源系统分为十个子系统：机构编制管理、人员信息管理、人事档案管理、考勤管理、薪资福利管理、社会保障管理、招聘管理、合同管理、查询统计管理、系统管理。

　　我负责人员信息管理子系统，这方面需要处理的业务逻辑比较少，表单比较多，要把握好与其它子系统的关联。

　　员工基本信息表是与其它子系统关联的桥梁，大部分表都涉及到与基本信息表的外键关联。

　　其中，职员编号(employeeId)是作为外键关联的字段，我给它设置了自增长。

　　有人认为在企业里，职员编号应该是有一定规律的数字，而不应该设置自增长。

　　这样的是想法很符合实际情况，后来我和两个组长讨论，认为自增长可以保证数据的唯一性，非自增长的主键在增加时可能遇到不可知的问题，并且其他组员的数据库已经设计好，改起来就麻烦了。

　　因此最终职员编号采用了自增长。

　　有了上面的共识，接下来的重要工作便是依次完成表的增删改查、数据校验。

　　其中，分页和批量删除是我计划最后完成的部分，并且一定要完成。

　　基本数据校验按各数据格式进行，例如手机号、e-mail等。

　　另一方面要对职员编号与姓名的一致性，职员编号的存进行验证，这些通过DAO里面的方法实现，针对出错，用JS给出友好的提示。

　　在做好基本功能的前提下，争取做出特色。

　　我尝试写了Hibernate分页、批量删除的代码，最后都测试成功。

　　同时加入了JS控件，对于一些有特殊格式要求的字段，防止用户填写错误(比如日期的填写格式为yyyy-mm-dd)，使系统更加人性化。

　　经过讨论，对员工基本信息主表及与其关联的所有表，配置级联删除。

　　当主表信息被删除时，与之外键关联的子表信息同时被删除。

　　回顾这段历程，遇到了一些瓶颈，例如批量删除时如何有效的处理选中的id