我一直在研究一个基本上是CRUD应用程序（创建，读取，更新，删除）的Web应用程序。最近，我开始研究我称之为“批准工作流程”。基本上，会为物料生成请求，然后将其发送给经理批准。根据请求的不同，不同的人需要批准请求或者将其发送回请求者进行修改。批准者需要跟踪批准已批准的内容以及请求者需要查看其请求状态的内容。
作为一名“CRUD”开发人员，我正在努力解决如何设计这个问题。我应该拥有哪些数据库表？如何跟踪请求的状态？我应该如何通知用户他们的请求发生的操作？
他们的设计模式可以帮助我吗？我应该在我的代码中绘制状态机吗？
我认为这是一个通用的编程问题，但如果它有所不同，我正在使用Django和MySQL。
有这样的设计模式。也许他们会有所帮助：
http://en.wikipedia.org/wiki/Workflow_patterns
工作流比简单的CRUD应用程序更像是状态驱动，所以是的，阅读状态机模式也会有所帮助。听起来你走在正确的轨道上。
对于数据建模，您可以拥有一个包含所有“批准”的表，其中状态字段是状态表的外键。
至于通知，这是您的应用程序在更改批准状态时必须执行的操作，它必须在其他位置查找以查看特定状态更改需要通知的人/事件（因此您必须跟踪实体会收到有关状态更改的通知。
批准==状态变更
状态更改==更新到更改的内容&&创建日志以记录更改的内容。
而已。
有趣的规则是“谁被允许进行更新？”，“哪些状态更改是合法更新？”，以及“哪些状态是死胡同？”
你正在构建一个有限自动机。状态是对象的属性。您通过更新其状态来“推动工作流程”。
正如许多人所说，批准它正在将其推向一个新的状态。
我遇到的事情是，我经常发现用户希望将事物处于相同的“状态”，但也记录事情处于该状态的不同步骤或任务中。例如，用户可能想要区分“请求”和“进行中”。从批准的角度来看，请求和进行中都未经批准（打开）。如果某些东西从批准回到未批准（开放），他们可能会称之为“需要审核” - 但它仍未获得批准。
所以你可能想要这样的东西：
要求：开放
正在进行中：打开
要求审核：打开
已批准：已批准
随着时间的推移，您的用户可能需要更多“模式”或“任务”。如果你为每一个做出一个状态，你最终可能会比你或他们真正想要的更复杂。如果你让用户拥有他们想要的“模式”或“任务”，与状态有多对一的关系，从你的角度来看会更简单，但从用户的角度来看会更精确。
这经常出现在我们面前，我们制作了一个通用的路由系统。对于你正在做的事情来说，这可能有点过头了，但是欢迎你去挖掘它的想法。它允许使用链（顺序批准）或星形（广播）和最小投票批准将任意内容路由到任意用户。 Here是模式的自动生成的ERD。
基本上我们有一个包含一个或多个路由方案列表的路由方案。每个列表可以是链式或星型，整个方案可以作为链或星型启动。每个列表和整个方案都可以有自己的votes_to_approve。这意味着你可以有一个带有“star”类型的方案，它有两个列表，一个是星形，一个是链。整个方案的vote_to_approve为1，因此如果任一列表批准，则整个工作流程都被批准。链表可以具有等于成员数量的votes_to_approve，以便每个成员必须在下一个成员可以投票之前批准，并且第一个拒绝批准该列表。在星形列表中，您可以使vote_to_approve为1，以便该列表中的任何人都可以立即批准整个工作流程
这些方案无限期保存，一旦设置就可以重复使用。要实现一个方案，路由表中的条目是使用scheme_id，要路由的东西以及批准和拒绝文本等一些细节。然后，“routing_”表存储已实现方案的状态。
我们使用跨应用程序事件系统来发送电子邮件，或在路由更改状态时通知其他应用程序。
我现在在一个类似的项目（不同的平台/ DB）。
我有一个数据库应用程序具有不同级别的用户权限，他们可以CRUD的记录类型。在大多数情况下，我在代码中控制允许的操作。
但是，对于许多构造，我有一个构造的“状态代码”，然后定义（再次，在代码中）谁可以对该构造做什么，以及他们可以将它移动到哪些状态代码。