基于工作流的系统的数据库设计
Database design for Workflow based system
我正在为工作流程复杂的销售公司设计数据库。流程从销售官开始，然后转到团队负责人，最后转到经理。在批准提案之前，经理会将其发送给部门业务分析师。在得到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
请对设计提出建议。
这类问题提出的问题很多。例如：
- 在您的 table 中，Workflow 将状态转换定义为将分配从一个用户更改为下一个用户。
- 这可能是个问题。假设用户生病、离开、休假……那么你的流量就被阻塞了。
- 它也不允许组概念。
- 其他人（比如我）会定义一个转换 table。 StartState, NextState.
- 工作流将是一个转换列表。
- 每个转换都要求用户属于特定类型。或者从用户管理的角度，具有一定的角色，或者是一个组的成员。
如果您的工作流程是固定的并且不会更改，那么您的方法可能没问题。但是，如果工作流程灵活或可能会更改/调整，则您应该采用更灵活的方式。
您所谈论的设置类型让我想到了 Jira 软件（来自 Atlassian），您可以在其中定义工单、状态、工作流和用户。您是否可以使用（即购买或开源）工作流管理工具？长期 运行 可能比建造一个便宜。
您的模型可能会扩展为包括：
- 客户。提案是针对哪个客户的？
- 负责审核工作流程并推动工作流程的销售代表或客户经理是谁？
- link其他系统：如何link采购，应收账款，...
今天所有这一切，这需要深入分析，这在像这样的媒体上很难做到 (SO)。
编辑：20181004
我根据您的评论添加了以下模型。我决定将工作流放入数据库中：
注释（tables 按字母顺序排列）：
员工
- 可以通过 Employee_has_EmployeeRole table.
每个员工 link 加入 n 个 EmployeeRole
提案
- 一位员工 link 被任命为销售人员，因为他发起了一项提案。
- link编辑了一个工作流，因为不同的提案可能存在许多工作流。
过渡
- 两次链接到州。开始状态和结束状态。
- EmployeeRole linked，以确定员工必须具有哪个角色才能执行此转换。
- 将由应用程序执行。
Workrlow_has_Transition
- 将转换链接到工作流。
- 此处记录完成转换的员工。
- 它的完成日期也保存在这里。
- OrderInWorkflow 只是一个数字，可让您订购 Workflow_has_Transition 个条目。
- 应用程序必须确保在其他低阶转换完成之前不完成转换（即 DoneDate 为空）。
- 它还将验证尝试完成它的员工是否具有正确的 EmployeeRole。
现在，员工群体的概念。您可以说一个组是具有相同 EmployeeRole 的员工。因此，当您的应用程序需要发送通知时，请将其发送给具有转换所需角色的所有用户。这避免了您必须创建一个 EmployeeGroup table，其中 link 员工在一起。
应用场景：
- 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 被拒绝了两次，但第三次获得批准。
有很多这样的场景会显示您的模型的弱点，您可以在完成此分析时修复这些弱点。现在它还不完美，我没有花很多时间在上面。但这是一个起点并说明了我的想法。
我建议您在此
中构建一些结构
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 }
因为我认为可能有多个相同类型的用户，而且你会想要评论为什么 RequestAction 被拒绝，请求者会向接收者发出 requestAction，如果它完成它会显示在系统中处理同一个请求的多个请求操作时让生活更轻松。
希望这对您有所帮助，但我建议您制作流程图并查看所有可能的用例。
我正在为工作流程复杂的销售公司设计数据库。流程从销售官开始，然后转到团队负责人，最后转到经理。在批准提案之前，经理会将其发送给部门业务分析师。在得到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
请对设计提出建议。
这类问题提出的问题很多。例如：
- 在您的 table 中，Workflow 将状态转换定义为将分配从一个用户更改为下一个用户。
- 这可能是个问题。假设用户生病、离开、休假……那么你的流量就被阻塞了。
- 它也不允许组概念。
- 其他人（比如我）会定义一个转换 table。 StartState, NextState.
- 工作流将是一个转换列表。
- 每个转换都要求用户属于特定类型。或者从用户管理的角度，具有一定的角色，或者是一个组的成员。
如果您的工作流程是固定的并且不会更改，那么您的方法可能没问题。但是，如果工作流程灵活或可能会更改/调整，则您应该采用更灵活的方式。
您所谈论的设置类型让我想到了 Jira 软件（来自 Atlassian），您可以在其中定义工单、状态、工作流和用户。您是否可以使用（即购买或开源）工作流管理工具？长期 运行 可能比建造一个便宜。
您的模型可能会扩展为包括：
- 客户。提案是针对哪个客户的？
- 负责审核工作流程并推动工作流程的销售代表或客户经理是谁？
- link其他系统：如何link采购，应收账款，...
今天所有这一切，这需要深入分析，这在像这样的媒体上很难做到 (SO)。
编辑：20181004
我根据您的评论添加了以下模型。我决定将工作流放入数据库中：
注释（tables 按字母顺序排列）：
员工
- 可以通过 Employee_has_EmployeeRole table. 每个员工 link 加入 n 个 EmployeeRole
提案
- 一位员工 link 被任命为销售人员，因为他发起了一项提案。
- link编辑了一个工作流，因为不同的提案可能存在许多工作流。
过渡
- 两次链接到州。开始状态和结束状态。
- EmployeeRole linked，以确定员工必须具有哪个角色才能执行此转换。
- 将由应用程序执行。
Workrlow_has_Transition
- 将转换链接到工作流。
- 此处记录完成转换的员工。
- 它的完成日期也保存在这里。
- OrderInWorkflow 只是一个数字，可让您订购 Workflow_has_Transition 个条目。
- 应用程序必须确保在其他低阶转换完成之前不完成转换（即 DoneDate 为空）。
- 它还将验证尝试完成它的员工是否具有正确的 EmployeeRole。
现在，员工群体的概念。您可以说一个组是具有相同 EmployeeRole 的员工。因此，当您的应用程序需要发送通知时，请将其发送给具有转换所需角色的所有用户。这避免了您必须创建一个 EmployeeGroup table，其中 link 员工在一起。
应用场景：
- 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 被拒绝了两次，但第三次获得批准。
有很多这样的场景会显示您的模型的弱点，您可以在完成此分析时修复这些弱点。现在它还不完美，我没有花很多时间在上面。但这是一个起点并说明了我的想法。
我建议您在此
中构建一些结构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 }
因为我认为可能有多个相同类型的用户，而且你会想要评论为什么 RequestAction 被拒绝，请求者会向接收者发出 requestAction，如果它完成它会显示在系统中处理同一个请求的多个请求操作时让生活更轻松。
希望这对您有所帮助，但我建议您制作流程图并查看所有可能的用例。