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

Question

我正在为工作流程复杂的销售公司设计数据库。流程从销售官开始，然后是团队主管，最后是经理。在批准提案之前，经理会将其发送给部门业务分析师。在得到 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

请就设计提出建议。

Answer 1

此类问题引发的问题很多。前任：

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

如果您的工作流程是固定的并且不会发生变化，那么您的方法可能没问题。但是如果工作流程是灵活的或者可能会改变/适应，你应该采用更灵活的方法。

您所谈论的设置类型让我想起了 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 你想记录一个 Transition 的拒绝吗？那要怎么处理呢？您向具有该转换角色的员工发送通知以对其进行审核？

Ex.2 您想保留提案的完整历史记录吗？前任。Transition X 被拒绝两次，但第三次获得批准。

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