2016年2月2日实习日志

最近临近过年，项目已然上线，所以手上的任务比较清闲，闲来无事总结一下最近做的事情吧，顺便着重记录一下今天的一个关于审批流程的设计思路。
回顾最近这些日子，发现收获有限，主要就是研究了一下网站攻防，主要包括csrf攻击和xss攻击两种攻击方式，主要的一个体会就是之前看的一个电影的名字：没有一个系统是真正安全的。对于黑客技术也有了初步的一个认识，自己掌控不了的东西尽量不要拿出手，就像夺命十三剑的第十五剑，控制，而不被控制。
前些日子还做了一个qq互联的东西，实际上就是一个oauth的升级，是从1.0升级到2.0，其中就是一些oauth认证的一个过程，之前做过的微信认证也是基于oauth的。

昨天还看了一些关于js闭包的东西，这个东西理解起来不是特别容易，说一下自己的体会吧，我的理解就是把js实现某一特定功能的代码类似于面向对象的原理封装起来，但不是封装成一个类，而是封装成一个方法，从而实现方法的嵌套使用，对应这部分理解还不是很透彻，以后还要多多学习。

然后就是明年可能要参与一个办公系统的开发，主要就是涉及一个审批流程的设计，主体就是这样，然后由我们部门大神带领去做这个东西，还是能够从大神身上学到很多东西的。
比如：
1、系统设计要先考虑数据的扩展性再去考虑程序的扩展性，如果从数据层面上就达不到扩展的要求，程序上几乎是无法实现的。
2、多对一和多对多关系在数据库的存储上应该是存成两张表的。

下面来详细介绍以下关于审批流程的设计方案：
先介绍一下该审批的应用场景：
某公司，要实现线上请假过程，需要事先设定审批工程，包括几级审批，一审的审批人，二审的审批人…设定完成之后，由请假人提交请假申请，也就是对应实际情况中的写假条过程，在提交假条过程时，可以指定审批人（该审批人可以不在系统规定的审批人中），提交之后，按照审批流程逐步审批，直到最后一级审批人通过，审批流程结束（改过程可以对应实际情况中的组长签字->部门经理签字->人事部签字的过程）。

这就是这个请假流程的具体步骤，下面就来介绍以下关于该步骤的数据库设计方式：

以上就是总共涉及到的一共八个表的内容，我讲一下几个关键表的运作方式吧。

这是手写的一个关键数据库和流程，当然这是我的想法，跟组长讨论之后做了一些修改，但是我依然保留我的意见。

其中最后敲定的流程就是把节点表和记录表分开存，流程表的附表作为节点表，其中流程已经设定好了，就按流程来，不需要创建假条的时候创建流程，而是存一个记录的过程。然后把在节点表中存系统的操作人，在审批人表中存所有可见的人与假条的对应关系。
嗯，对，就是这样。