Workflows are more state-driven than simple CRUD apps, so yes, reading up on state-machine patterns will help too. It sounds like you're on the right track.
As for data modelling, you could have a table of all "approvals", with a state field that is a foreign key to a table of states.
As for notifications, that's something your app will have to do when it changes the state of an approval, it will have to look up somewhere else to see who/what needs to be notified for a particular statechange (so you will have to track what entities get notified for which state-changes).
As many have said, approving it is moving it into a new state.
Something to consider that I have run into is that I've found frequently users want to have things in the same "state", but also record that things are in a different step or task in that state. For instance, the users may want to distinguish between "requested" and "in process". From an approval perspective, requested and in process are both unapproved (open). If something goes from approved back to unapproved (open), they might call that "review required" - but it's still not approved.
So you might want something like this:
Current Task : State
Requested : Open
In Process : Open
Review Required : Open
Approved : Approved
As time goes on your users will probably want more "modes" or "tasks". If you make a state for each of these you can end up with a lot more complexity than you or they really wanted. If you let the users have as many "modes" or "tasks" as they want, with a many to one relationship with the states, it will be simpler from your perspective, but more precise from the user's perspective.
This came up for us so often that we made a generic routing system. It is probably overkill for what you are doing but you are welcome to mine it for ideas. It allows the routing of arbitrary content to arbitrary users using either a chain (sequential approval) or star ( broadcast) with and a minimim votes to approve. Here is an auto-generated ERD of the schema.
Basically we have a routing scheme that contains one or more routing scheme lists. Each list can be either chain or star, and the whole scheme can be initiated as a chain or star. Each list and the whole scheme can have its own votes_to_approve. This means that you could have a scheme with type "star" with two lists, one star and one chain. The whole scheme can have votes_to_approve of 1 so if either list approves, the whole workflow is approved. The chain list can have votes_to_approve equal to the number of members so that each member has to approve before the next member can vote, and the first to disapprove kills that list. In the star list you can have votes_to_approve of 1 so that anyone in that list can instantly approve the whole workflow
These schemes are saved indefinitely and can be re-used once set up. To implement a scheme, an entry in the Routing table is made with the scheme_id, the thing to be routed and some details like approval and disapproval text. The "routing_" tables then store the state of the implemented scheme.
We use a cross-application event system to send emails, or inform other applications when the route changes state.
I'm in a similar project now (different platform / DB).
I have a DB app with different levels of user permissions as to what kinds of records they can CRUD. In most cases, I control the allowable operations in code.
However, for a number of the constructs, I have a "status code" for the construct, which then defines (again, in code) who can do what to that construct, and what status codes they can move it to.
发布评论
评论（5）
批准==状态更改
状态更改==更新更改的内容&&创建日志来记录发生的变化。
就是这样。
有趣的规则是“谁可以进行更新？”、“哪些状态更改是合法更新？”以及“哪些状态是死胡同？”
您正在构建一个有限自动机。状态是对象的属性。您可以通过更新其状态来“通过工作流程”推送某些内容。
Approval == State Change
State Change == Update to the thing that changed && Creation of a log to record that something changed.
That's it.
The interesting rules are "who's allowed to do the update?", "Which state changes are legal updates?", and "which states are dead-ends?"
You're building a Finite Automaton. The state is an attribute of an object. You push something "through the workflow" by updating its state.
有这方面的设计模式。也许他们会有所帮助：
http://en.wikipedia.org/wiki/Workflow_patterns
工作流程比简单的 CRUD 应用程序更加受状态驱动，因此，阅读状态机模式也会有所帮助。听起来你走在正确的轨道上。
至于数据建模，您可以拥有一个包含所有“批准”的表，其中一个状态字段是状态表的外键。
至于通知，这是您的应用程序在更改批准状态时必须执行的操作，它必须在其他地方查找以查看特定状态更改需要通知谁/什么（因此您必须跟踪什么）实体会收到状态更改的通知）。
There are design patterns for this. Maybe they will help a bit:
http://en.wikipedia.org/wiki/Workflow_patterns
Workflows are more state-driven than simple CRUD apps, so yes, reading up on state-machine patterns will help too. It sounds like you're on the right track.
As for data modelling, you could have a table of all "approvals", with a state field that is a foreign key to a table of states.
As for notifications, that's something your app will have to do when it changes the state of an approval, it will have to look up somewhere else to see who/what needs to be notified for a particular statechange (so you will have to track what entities get notified for which state-changes).
正如许多人所说，批准它正在将其带入一个新的状态。
我遇到的需要考虑的事情是，我发现用户经常希望事物处于相同的“状态”，但也记录事物处于该状态的不同步骤或任务。例如，用户可能希望区分“已请求”和“处理中”。从批准的角度来看，已请求的和正在处理的都是未批准的（开放的）。如果某件事从批准回到未批准（开放），他们可能会称之为“需要审查” - 但它仍然没有获得批准。
因此，您可能需要这样的内容：
当前任务：
请求状态：
正在处理中：
打开需要审核：打开
已批准：已批准
随着时间的推移，您的用户可能会需要更多“模式”或“任务”。如果你为每一个都制定一个状态，你最终会得到比你或他们真正想要的复杂得多的结果。如果你让用户拥有尽可能多的“模式”或“任务”，并且与状态具有多对一的关系，那么从你的角度来看，它会更简单，但从用户的角度来看，它会更精确。
As many have said, approving it is moving it into a new state.
Something to consider that I have run into is that I've found frequently users want to have things in the same "state", but also record that things are in a different step or task in that state. For instance, the users may want to distinguish between "requested" and "in process". From an approval perspective, requested and in process are both unapproved (open). If something goes from approved back to unapproved (open), they might call that "review required" - but it's still not approved.
So you might want something like this:
Current Task : State
Requested : Open
In Process : Open
Review Required : Open
Approved : Approved
As time goes on your users will probably want more "modes" or "tasks". If you make a state for each of these you can end up with a lot more complexity than you or they really wanted. If you let the users have as many "modes" or "tasks" as they want, with a many to one relationship with the states, it will be simpler from your perspective, but more precise from the user's perspective.
我们经常遇到这个问题，因此我们制作了一个通用的路由系统。对于你正在做的事情来说，这可能有点过分了，但欢迎你挖掘它的想法。它允许使用链（顺序批准）或星形（广播）将任意内容路由到任意用户，并以最低投票数进行批准。 这里是自动生成的架构 ERD。
基本上，我们有一个包含一个或多个路由方案列表的路由方案。每个列表可以是链式或星形，整个方案可以作为链式或星形启动。每个列表和整个方案都可以有自己的 votes_to_approve。这意味着您可以有一个“星”类型的方案，其中有两个列表，一个星和一个链。整个方案的 votes_to_approve 可以为 1，因此如果任一列表获得批准，则整个工作流程都会获得批准。链表的 votes_to_approve 可以等于成员数量，这样每个成员都必须在下一个成员投票之前批准，而第一个不批准的成员会杀死该列表。在星级列表中，您可以将 votes_to_approve 设置为 1，以便该列表中的任何人都可以立即批准整个工作流程。
这些方案将无限期保存，并且一旦设置即可重复使用。为了实现一个方案，路由表中的一个条目由scheme_id、要路由的事物以及一些详细信息（如批准和不批准文本）组成。然后，“routing_”表存储已实施方案的状态。
我们使用跨应用程序事件系统来发送电子邮件，或在路由状态更改时通知其他应用程序。
This came up for us so often that we made a generic routing system. It is probably overkill for what you are doing but you are welcome to mine it for ideas. It allows the routing of arbitrary content to arbitrary users using either a chain (sequential approval) or star ( broadcast) with and a minimim votes to approve. Here is an auto-generated ERD of the schema.
Basically we have a routing scheme that contains one or more routing scheme lists. Each list can be either chain or star, and the whole scheme can be initiated as a chain or star. Each list and the whole scheme can have its own votes_to_approve. This means that you could have a scheme with type "star" with two lists, one star and one chain. The whole scheme can have votes_to_approve of 1 so if either list approves, the whole workflow is approved. The chain list can have votes_to_approve equal to the number of members so that each member has to approve before the next member can vote, and the first to disapprove kills that list. In the star list you can have votes_to_approve of 1 so that anyone in that list can instantly approve the whole workflow
These schemes are saved indefinitely and can be re-used once set up. To implement a scheme, an entry in the Routing table is made with the scheme_id, the thing to be routed and some details like approval and disapproval text. The "routing_" tables then store the state of the implemented scheme.
We use a cross-application event system to send emails, or inform other applications when the route changes state.
我现在正在进行一个类似的项目（不同的平台/数据库）。
我有一个数据库应用程序，具有不同级别的用户权限，决定他们可以 CRUD 的记录类型。在大多数情况下，我控制代码中允许的操作。
然而，对于许多构造，我有一个构造的“状态代码”，然后它定义（再次在代码中）谁可以对该构造执行什么操作，以及他们可以将其移动到什么状态代码。
I'm in a similar project now (different platform / DB).
I have a DB app with different levels of user permissions as to what kinds of records they can CRUD. In most cases, I control the allowable operations in code.
However, for a number of the constructs, I have a "status code" for the construct, which then defines (again, in code) who can do what to that construct, and what status codes they can move it to.