急！送分！多贴少补！ 请教各位老大，一个OA项目怎么架构系统和功能模块？

所谓的公文 和发帖差不多吧 嘿嘿 加上个可以回帖的顺序就应该差不多了 LZ把很多事情搞混了权限判断：
认证 也就是LZ说的可以用SESSION 其实就是知道当前用户是谁
身份 也就是LZ说的 IS_BOSS 之类的东西 其实就是用户分组 一般这个组是可以继承的或者多重身份
权限 权限完全可以用1个权限表来完成 实际情况一般是用户组+特别权限工作流 
简化来说
所有者-》组1-》组2-》组3-》组4-》OVER
一般工作流都是活动的 因为有N个工作流公文状态
静态标签0和99 标志未进入工作流和已经完成
其他标签一般和 工作流中的编号对应就可以了
这里为了方便查找 应该在单独字段中记录 下一个状态的用户身份
这里有个方向的问题 工作流不是单向的而是双向的 可以向下继续也可以向上重来看LZ贴出来的资料 没考虑部门的问题 这只是个部门应用？俺只写过本公司的应用大概就是这个样子 肯定不是LZ所说的正规～！ 啥叫正规?

解决方案 »

  1.   

    这种具体型的项目，可以参考uml模式开发权限问题，一般比较复杂，也是OA中比较难的，可看权限角色模型——标准RBAC模型，可以设专门的API
      

  2.   

    简单的一个思路，从简单做起1.创建公文 
    2.修改未批公文 
    3.删除未批公文 
    4.给领导批阅 
    5.给领导传阅 公文表（公文的基本信息，里面包括公文的状态）
    公文流转记录表 （公文的流转记录，其中包括 更改人，从什么状态，改到什么状态，做了什么批示）
    比如说创建的话就是 从0变成1 修改未批公文 从1变成2  当状态变成 6的时候，这个公文流转完毕把公文流转中的几个过程，定义成几个状态，然后在后台中写个函数，判断每次是否可以从状态i变成状态j，防止跨N个状态
      

  3.   

    谢谢各位高手。2楼的兄弟思路很清晰，真是难得的人才1.认证的话，准备用user表中username写入session2.部门的话，肯是有的，这里是在user表增加dept_id字段，然后创建dept表（id name），user.dept_id 对应 dept.id3.用户分组的话，准备在user表中增加，is_creater，is_boss，，is_manager，is_staff，来分组  比如我要运行部的经理  那么就 select from user where is_manager = 1 and dept = ‘经理'4.感觉权限应该是继承的关系，而用户组应该是一个多重的关系  如果多重身份的话就应该不用权限表而是用多个字段了，是不是？
    以上只是很不成熟的想法，希望大家多批评
    还有请教下ten789  
    这里为了方便查找 应该在单独字段中记录 下一个状态的用户身份   这句话没理解能否详细点？一般工作流都是活动的，因为有N个工作流，这个活动工作流是否需要编程实现，还是默认的？继续加分！ 谢谢
      

  4.   

    最好写USER_ID 使用主键查询要快还持久
    部门 分组 级别 这3个最好单独建表记录 但几乎每次都要用到而且内容很少 还应该放到高速缓存中
    单独建表的好处就是活动 记录在USER表中字段很难修改的
    权限肯定是要继承的而且最好能多重继承
    还是推荐权限表 字段总归是固定的不好更改而且效率要差因为每个工作流是不一样的 所以就无法从状态中直接得知下一步的操作 还要查询工作流 为了简化查询就把下一步的操作直接写在字段里 当然你喜欢子查询甚至存储过程可以不用 这个字段其实就是个缓存是不可信的 在进入处理环节还要再次验证活动工作流是记录在表里的而且不是LZ习惯用的多字段 应该是很短由多行组成 看看DZ的数据结构会有发现
    这东西肯定不会内嵌在程序中最初俺也喜欢用多字段 建表的时候非常快 但开发到后期就会发现不足到了2次开发就想删了重来但又不能只好加字段 最后把表弄的N长再往下说点
    OA这东西负载很轻的所以不怕慢不怕大 应该用OO的方式开发 重用一次就给弄成方法 那些孤立的函数也给整进杂项类 静态调用
    为企业单独定制OA最烦的就是改 总改昨天说的今天就改