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），您可以在其中定义票证，状态，工作流程和用户。您是否可以使用（即购买或OpenSource）工作流管理工具？从长远来看，它可能比建造一个更便宜。

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

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

今天，这需要进行深入的分析，而这种分析很难在这种（SO）介质上进行。

编辑：20181004

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

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

员工
- 每个员工可以通过Employee_has_EmployeeRole表链接到n个EmployeeRole。
提案
- 由于员工发起提案，因此将其链接为销售员。
- 工作流程已链接在一起，因为针对不同的提案可能存在许多工作流程。
过渡
- 链接到州两次。起始状态和结束状态。
- 已链接EmployeeRole，以标识雇员执行此过渡必须具有的角色。
- 由应用程序执行。
Workrlow_has_Transition
- 将转换链接到工作流。
- 完成过渡的员工记录在这里。
- 完成日期也保存在这里。
- OrderInWorkflow只是允许您订购Workflow_has_Transition条目的数字。
- 应用程序必须确保在完成其他较低顺序的操作之前（即DoneDate为null），未完成过渡。
- 它还将验证要完成它的Employee是否具有正确的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是否要保留提案的完整历史记录？例如转换X被拒绝两次，但第三次被批准。

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

Answer 2

我建议您沿此安排一些地方

planRecoveryStrategy

因为我认为可能有多个相同类型的用户，所以您想对为什么RequestAction被拒绝的原因进行更多的评论，一个请求者将一个requestAction传递给接收者，如果完成，它将显示在当处理同一个Request的多个requestAction时，系统使工作变得更轻松。

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

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

2 个答案: