任务管理模块的数据库设计

[jaymehe668]

1.新建任务
系统提供创建任务的模版,填写创建任务的相关信息,并指派任务各个步骤的任务执行人员、参阅人员.
2.新建子任务
任务流程中,某个环节可以根据实际需要创建子任务,将任务分拆到不同的工作人员.

由上可见,一个任务(id,任务名称,任务内容)下可能有多个步骤(id,执行人,执行内容),一个步骤下有0或1个子任务(id,子任务名称,子任务内容,执行人).

想问下,这样的数据库应该怎样来设计比较好?

小弟我对数据库设计者方面很菜,求高人指点迷津~!

[以专业开发人员为伍]

先不要急于整什么“数据库设计”，先把业务描述清楚，这是关键。 例如举个业务流实例： 1. 用户保修。保修类-暖气不热。下发工单给第19维修所。 2. 第19维修所收到执行工单，与用户联系，录入初步资料。 3. 第19维修所有施工人员可派，于是排人出现场，并通知用户。 4. 第19维修所人员到达现场，检修发现故障难以诊断，需要请求设备XXX。 5. MM公司收到申请工单，准备设备XXX以及其它仪器设备。 6. MM公司派人出现场，并通知第19维修所。 7. MM公司到达现场，诊断故障为KK。 8. 第19维修所修理故障KK，并登记使用一堆材料LLL。 9. 客服人员打电话给用户，了解检修情况。问题没有完全处理。 10. 第19维修所接到指令，重新与用户联系，重新安排人员出现场检修。 11. 第19维修所人员到达现场，修理完成。并登记使用一堆材料UUU。 12. 客服人员打电话给用户了解检修情况。问题完全处理完毕。 13. 通知财务到第19维修所上缴两笔维修费和一笔XXX使用费。 14. （在13的同时）通知MM公司一笔费用。 15. 财务缴费完毕。 16. MM公司费用支付。 这类流程要充分搞清楚业务内容，然后才是数据库。做项目时中最怕的就是会编程而不懂业务的开发人员。如果你重新搞清楚各种业务的内容，再去编程时就会很快进入角色。

[以专业开发人员为伍]

这里是我以前写过的一个简单的应急任务指挥系统的基本结构

    public class Task
    {
        public string Id { get; set; }   //工单号。必须唯一，用户经常使用。
        public int Version { get; set; }  //任务更新版本号。每当修改任务数据，包括扩展字段中的数据，服务器端都会将版本号加一（这也就意味着前端传递给后端的版本号通常会被自动忽略）。
        public string PrevId { get; set; }    //前一工单号。
        public string SharingId { get; set; } //任务流程公共的表单头信息——热线受理信息。
        public LatLng Position { get; set; }
        public string GIS { get; set; }    //GIS系统中图形编号。当不需要显示时，应该删除此编号。
        public DateTime CreateTime { get; set; }     //创建任务时间
        public DateTime SharingCreateTime { get; set; }     //冗余记录工单对应的热线接听创建时间。用于在流转中计算任务报警时间。
        public DateTime FirstAlarmTime { get; set; }    //初级报警时间。此时默认地将ViewState属性设置为FirstAlarm
        public DateTime SecondAlarmTime { get; set; }   //严重报警时间。此时默认地将ViewState属性设置为SecondAlarm
        public DateTime CompleteTime { get; set; }    //完成任务时间
        public string LoginName { get; set; }           //完成此任务的负责人
        public string DisplayName { get; set; }         //完成此任务的负责人
        public TaskStatusDefine Status { get; set; }       //任务状态。
        public PermissionMatcher Matcher { get; set; }    //权限——即任务接收者的匹配条件。
        public string TypeName { get; set; }      //任务类型名称。
        public string ViewState { get; set; }     //显示外观，或者叫状态外观。这个属性决定了前端如何从后端下载表现层定义（既每一种任务下的SpiritImages子目录）。
        public string AttachmentFileName { get; set; }      //附件文件的名字
        public string 客户端程序识别号 { get; set; }    //这主要是（大量）异步并行操作的客户端程序用于识别将来服务器推送的任务信息的，服务器端从来不修改此内容。
    }

这基本上是其它上百种具体的任务类型的父类，其它具体的任务都是从这个简单的类型继承的。 你所说的任务，在我那里叫做“任务流”。其实一个任务流的类型，是由第一个任务（通常是呼叫中心值班经理所确立的第一个工单）的类型而决定的。 但是其实没有任何一个任务里的流程的实际执行实例可能是固定模式化的。例如给一个病人做阑尾炎手术，可能随着这个任务流的流动，最后变成了同时要切除其一部分肝脏。你不能说这是两个任务，也不能说一个阑尾炎手术的结果就是切除肝脏。所以任务流就是一堆具体的任务的流动，没有固定的模式。

[以专业开发人员为伍]

关于“某个环节可以根据实际需要创建子任务”，这确实可以由用户预先定义一些规则，让系统自动化地读懂具体的工单信息从而自动下发新的工单。这部分的数据结构跟上述单纯地记录任务流程就不一样，这部分主要是记录用户（或者软件的售后服务工程师为用户）自定义的规则集。当这种规则达到很多，应该可以打印出很好看的“工作流图”，这就好象是“人立方图”一样。不过这是由系统自动打印的。而假设像很多“工作流系统”那样让用户去手工画密如蛛网的图，则是低效的、令人痛苦的。

[csdn_风中雪狼]

支持 sp1234

[devmiao]

如果是无限分级的，建议设计成通用的树数据结构 id parentid data