ERP业务表设计

[redshiliu]

业务单据有若干工作流程，每个流程对应该单据的一种状态，是将每种状态的单据分开各自表保存好还是不同状态的同种业务单据保存在一个表好？

[以专业开发人员为伍]

这要看你的“状态”是工作流状态还是业务状态。如果是工作流状态，那么它就是通用的，所有业务单据都有继承的状态。如果是各种业务自己的状态属性，那么就跟其它业务单据无关。 假设工作节点数据（或者是你说的“单据”）是这样定义的

public abstract class Task
{
    public string ID;
    public User 创建者;
    public DateTime 创建时间;
    public DateTime 最后一次修改时间;
    public User[] 接收者;
    public Rule[] 审核规则和计算结果;
    public Rule[] 流转规则和计算结果;
    public 状态 Status;
}

public enum 状态
{
    创建,
    等待后台计算流转规则,
    等待分支流程汇合,
    等待用户在客户端操作,
    结束,
    被管理员暂停,
    被管理员终止
}

public class 关阀门A操作 : Task
{
    public string 地点;
    public 呼叫中心系统任务  报修单编号;
    public GIS系统修改作业  临时上图;
    public string 操作人员;
    public 材料明细[ ] Items;
    ........
}

那么假设一个天然气公司的管网抢修工程队，它有5大类20小类工作任务，一共70种操作单据，那么显然这80种具体的单据都是从 Task 类继承的子类。那么显然，如果你说拿出“等待用户在客户端操作”这一状态的所有80种单据来设计成“一个”数据表，这显然是不现实的。显然应该是分成80个数据表，每一种单据一个表。 但是，上面的c#语法的实体类型模型已经说明了，实际上每一种操作单据都至少是Task表的一个外键关联表，因此这里的所有的“状态”字段也不在单据表中，而是在Task表中。只不过你要知道，每一个业务表都以外键来关联着唯一的Task表记录！ 很显然，随随便便地说什么“在一张表”和“在多张表”都是模糊问题的伎俩，没有将设计说明到位。 总结起来，其实就是要知道如何用关系数据库来表示“实体类型之间的继承关系”，要了解数据表的设计原理，而不是很简单地只知道问别人“状态设计在哪一个表”的问题。

[以专业开发人员为伍]

那么显然这80种具体的单据都是从 Task 类继承的子类 --> 那么显然这70种具体的单据都是从 Task 类继承的子类 在一些小公司，只知道做个什么“报销单、请假单”之类的也美其名曰“工作流”，而往往不能深入到任何一个实际的业务流程中，甚至他们的程序设计人员都“懒得”去熟悉超过10种以上的业务。这时候它们对数据库表的设计就会很随意，最终也用不起来。

[以专业开发人员为伍]

“业务单据有若干工作流程，每个流程对应该单据的一种状态”这种说法可能会产生另外一种错误的设计，认为一个实际工作的某个工作流转全过程就在“一个表中”，然后这个表中有多条记录（按照顺序号排序），然后每条记录弄一个所谓的“业务名称”（或者叫做“状态名称”）来表示具体这条记录是干什么事儿的。 可以肯定所有失败的工作流程序基本上都是这种概念来设计的东西。因为它没有想到业务是千变万化的、每个月可能都需要新增十几种，而且工作流设计也会每月都修改几十个，在系统刚开始使用时其变化非常频繁。比如说天然气公司的维修所接收到上级派来的工作，它不可能是用5个数据库表来记录80种业务，那样既非常混乱而且也不足以扩展。关键是那种表其实不能支持工作流系统的“用户自定义流程图、系统自动建表（而不需要程序员建表）、自动统计分析”等等灵活的设计意图的。 这种错误的“流程记录在一个表中”的数据库意识，是工作流项目越做越乱、越难以理解和升级档次、最终失败的主要原因之一。

[sp1234_maJia]

所有失败的工作流程序基本上都是这种概念来设计的东西 --> 基本上可以肯定，这种概念来设计的程序都是失败的工作流程序 原文在逻辑上有点问题，纠正一下。

[redshiliu]

受教了，谢谢

[把分全给哥]

多张表，希望你能理解