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

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

---

请就设计提出建议。

此类问题会引发许多问题。例：

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

如果您的工作流是固定的，并且不会发生更改，那么您的方法就可以了。但是，如果工作流是灵活的，或者可能会被更改/调整，那么您应该使用更灵活的工作流

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

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

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

时至今日，这一切都需要深入的分析，而在这样一种媒介上很难做到

---

编辑：20181004

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

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

• 雇员
  • 可以通过employee_has_EmployeeRole表将每个员工链接到n个EmployeeRole
• 提议
  • 员工被链接为销售人员，因为他发起了一项提案
  • 工作流是链接的，因为对于不同的提案可能存在许多工作流
• 过渡
  • 两次链接到状态。开始状态和结束状态
  • 将链接EmployeeRole，以确定员工执行此转换必须扮演的角色
  • 强制执行将由应用程序完成
• Workrlow\u具有\u转换
  • 链接到工作流的转换
  • 在此记录完成转换的员工
  • 完成日期也保存在这里
  • OrderInWorkflow只是一个数字，它允许您对Workflow\u具有\u转换条目进行排序
  • 应用程序必须确保在其他低阶转换完成之前未完成转换（即DoneDate为null）
  • 它还将验证试图完成该任务的员工是否具有适当的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您想保留提案的完整历史记录吗？例如，it过渡X被拒绝两次，但第三次批准

---

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

这些问题引发了许多问题。例：

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

如果您的工作流是固定的，并且不会发生更改，那么您的方法就可以了。但是，如果工作流是灵活的，或者可能会被更改/调整，那么您应该使用更灵活的工作流

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

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

• 客户。该提案是针对哪个客户的
• 谁是负责审核工作的销售代表或客户经理

  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 }