gpt4 book ai didi

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

转载 作者:行者123 更新时间:2023-11-29 14:30:27 26 4
gpt4 key购买 nike

我正在为一家有复杂工作流程的销售公司设计一个数据库。流程从销售主管开始,然后到团队领导,最后到经理。在批准提案之前,经理会将其发送给部门业务分析师。收到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软件(form Atlassian),在那里你定义了票据,状态,工作流和用户。您是否可以使用(即purchasse或OpenSource)工作流管理工具?从长远来看,它可能比建造一个更便宜。
您的模型可能会扩展到包括:
客户。建议客户是谁?
谁是负责审核工作流程并将其向前推进的销售代表或客户经理?
链接到其他系统:它如何链接到采购,应收账款。。。
迄今为止,这需要一个深入的分析,而这在这样的媒介上是很难做到的。
编辑:20181004
在您的评论之后,我添加了以下模型。我决定将工作流放入数据库:
enter image description here
注释(按字母顺序排列的表格):
雇员
每个员工都可以通过employee\has\u EmployeeRole表链接到n个EmployeeRole。
提案
由于一个雇员提出了一个建议,所以他与销售人员有联系。
工作流是链接的,因为许多工作流可能存在于不同的建议中。
过渡
链接到状态两次。开始状态和结束状态。
链接EmployeeRole,以标识员工必须执行此转换的角色。
强制执行将由应用程序完成。
工作状态转换
将转换链接到工作流。
在此记录完成转换的员工。
完成的日期也保存在这里。
OrderInWorkflow只是一个数字,允许您订购Workflow有转换项。
应用程序必须确保在其他较低阶的转换完成之前未完成转换(即DoneDate为空)。
它还将验证试图完成它的员工是否具有适当的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.

在浏览应用程序场景时,您将发现差距或丢失的项。
例1:您想记录拒绝转换的情况吗?那怎么处理呢?是否向具有该转换角色的员工发送通知以进行审阅?
例2.你想保留提案的全部历史记录吗?例如,it Transition X被拒绝两次,但第三次被批准。
有许多这样的场景会显示模型的弱点,在完成分析时可以修复这些弱点。现在还不完美,我没有花太多时间。但这是一个起点,说明了我的想法。

关于database - 基于工作流的系统的数据库设计,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/52620857/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com