基于工作流的系统的数据库设计答案

【问题标题】：Database design for Workflow based system基于工作流的系统的数据库设计
【发布时间】：2019-03-08 07:39:39
【问题描述】：

我正在为一家工作流程复杂的销售公司设计一个数据库。流程从销售官开始，然后是团队主管，最后是经理。在批准提案之前，经理会将其发送给部门业务分析师。在得到dba的意见后，他可以将提案发回给销售人员以在提案中进行修改。经理也可以拒绝该提议。如果满意，经理会将其转发给销售总监。目前设计的表格如下：-

Table: ProposalBasicData 

Id, Title, ProposalDate, Scope, Objective

Table: ProposalState

Id, Name
(Values - Forwarded , Approved ,  Returned  ,  Rejected)

Table: UserType

Id, Name
(Values - SalesOfficer, TeamLead,  Manager ,  DBA, DirectorSales)

Table: WorkFlow

Id, StartUserType, NextUserType, StateId, IsActive

Table: RequestAction 

Id, ProposalId, WorkFlowId, UserId, ActionDate

请就设计提出建议。

【问题讨论】：

标签： database postgresql database-design relational-database

【解决方案1】：

此类问题引发了许多问题。例如：

在您的表格中，工作流将状态转换定义为将分配从一个用户更改为下一个用户。
这可能是个问题。假设用户生病、离开、休假……然后您的流程被阻塞。
它也不允许组概念。
其他人（如我）会定义一个转换表。 StartState、NextState。
工作流将是一个转换列表。
每个转换都要求用户属于特定类型。或者从用户管理的角度来看，有一定的角色，或者是一个组的成员。

如果您的工作流程是固定的并且不会更改，那么您的方法可能没问题。但是，如果工作流程是灵活的或可能会更改/调整，您应该采用更灵活的方式。

您所说的设置类型让我想到了 Jira 软件（来自 Atlassian），您可以在其中定义工单、状态、工作流程和用户。您是否可以使用（即购买或开源）工作流管理工具？从长远来看，它可能比建造一个更便宜。

您的模型可能会扩展为包括：

客户。提案是针对哪个客户的？
谁是负责审核工作流程并将其向前推进的销售代表或客户经理？
链接到其他系统：它如何链接到采购、应收账款……

到目前为止，这需要进行深入分析，而这在诸如此类 (SO) 的媒体上是很难做到的。

编辑：20181004

我在您的评论之后添加了以下模型。我决定将工作流程放入数据库中：

备注（按字母顺序排列的表格）：

员工
- 每个员工都可以通过 Employee_has_EmployeeRole 表链接到 n 个 EmployeeRole。
建议
- 一名员工被链接为销售官，因为他发起了一项提案。
- 工作流是链接的，因为不同的提案可能存在许多工作流。
过渡
- 两次链接到状态。开始状态和结束状态。
- 已链接 EmployeeRole，以确定员工必须具有哪个角色才能执行此转换。
- 强制执行将由应用程序完成。
Workrlow_has_Transition
- 将转换链接到工作流。
- 完成转换的员工记录在这里。
- 完成日期也保存在这里。
- OrderInWorkflow 只是一个允许您订购 Workflow_has_Transition 条目的数字。
- 应用程序必须确保在其他低阶转换完成之前没有完成转换（即 DoneDate 为空）。
- 它还将验证尝试完成它的员工是否具有正确的 EmployeeRole。

现在，员工组概念。您可以说一个组是具有相同 EmployeeRole 的员工。因此，当您的应用程序需要发送通知时，请将其发送给具有转换所需角色的所有用户。这避免了您必须创建一个将员工链接在一起的 EmployeeGroup 表。

应用场景：

- Start a Proposal
    - Verify that the user trying to start a new one has the role "Sales Officer"
    - Collect basic information.
    - Link the Sales Officer to it (current user).
    - Link a Workflow to it.  Only propose the workflows which have at least 1 Workflow_has_Transition.
    - Send a notification to the Employee(s) which have the EmployeeRole for the first Workflow_has_Transition for this new Workflow.
    - These employees receive a notification.
- Progressing through the workflow
    - An employee receives a notification about a Proposal and it's "todo" Transition.
    - Employee views Proposal and Workflow (use the OrderInWorkflow to ORDER BY Transitions).
    - Employee approves if he has the proper EmployeeRole, fill DoneBy_idEmployee and DoneDate.

在浏览您的应用场景时，您会发现差距或缺失的项目。

Ex.1 是否要记录对转换的拒绝？那要怎么处理呢？您向具有该转换角色的员工发送通知以对其进行审核？

Ex.2 是否要保留提案的完整历史记录？前任。它Transition X 两次被拒绝，但第三次被批准。

有许多这样的场景会显示您的模型的弱点，您在完成此分析时会修复这些弱点。现在它并不完美，我没有花很多时间。但这是一个起点，说明了我的想法。

【讨论】：

感谢您的回复。在我的工作流程中，从用户类型转换到用户类型。因此，如果一个用户生病了，另一个用户将被分配该类型。如果将来团队负责人需要将提案返回给销售代表，那么该转换将添加到工作流表中。请说出您的看法。
选择是否将工作流包含在数据库中。如果不是，则需要更改代码以实现新的转换。如果是，它会使代码更通用，但您必须管理转换组合以生成工作流。
再次感谢。如果转换表必须有 startstate、nextstate 列，你能告诉我如何将它与用户和用户组链接吗？
谢谢。对于我的示例，我将使用States 作为SentBySalesOfficer、ApprovedByTL、SentToDba 等。如果将来Team Lead 自己可以拒绝提案，那么只需在State 表中添加一个状态并在Transition 表中添加相关的转换。请发表评论。
我看到了两种可能性。如果只是为了审计目的，一个简单的文本日志（每个提案一个）就足够了。或者，如果数据库大小不是问题，则可以将此日志存储在另一个表中。然后，如果您需要回滚到以前的版本，您是对的，您必须保留所有内容。

【解决方案2】：

我建议您在此基础上构建一些结构

ProposalBasicData {PBID,Title, ProposalDate,Scope,Objective} 
ProposalState {PSID,Name}
UserType {UTID,Name}
User {UID,Name,UTID(Usertype UTID FK) }
Request{ RID, StartUID, StartDate ,PSID, IsActive } 
RequestAction {AID,RID, RequesterUID, ReceiverUID, Date, Comments, IsCompleted }

因为我认为可能有多个相同类型的用户，更重要的是，您希望让 cmets 了解 RequestAction 被拒绝的原因，请求者会向接收者发出 requestAction，如果完成，它将显示在处理同一请求的多个 requestAction 时，系统使生活更轻松。

希望这会有所帮助，但我建议您制作流程图并查看所有可能的用例。

【讨论】：