最佳实践:在数据库中存储项目的工作流状态?

时间:2008-09-22 18:56:12

标签: database database-design refactoring workflow

我有一个关于如何处理存储复杂工作流状态以便在数据库中处理任务的最佳实践的问题。我一直在网上看无济于事,所以我想我会问社区他们认为最好的。

这个问题出自我在之前的问题中给出的相同“BoxItem”示例。在我的系统中跟踪这个“BoxItem”,因为它上面执行了各种任务。任务可能会持续几天并且与人工交互,因此BoxItem的状态必须保持不变。谁完成了任务(如果适用),并且还必须跟踪任务完成的时间。

首先,我通过在“BoxItems”表中为每个需要完成的人工交互任务添加三个字段来解决这个问题:

时的 TASKNAME 完整

日期 TASKNAME 完整

用户的 TASKNAME 完整

当工作流程很简单时,这种方法很有效......但现在它已经发展成为一个复杂的过程(在流程中有> 10个可能的人工交互......其中大约一半是可选的,可能会也可能不会完成对于BoxItem,导致我开始添加“Do TaskName ”字段以及那些可选任务),我发现应该是一个简单的表现在有40个左右的字段完全致力于保留这种国家信息。

我发现自己在问是否有更好的方法来做这件事......但我不知所措。

我的第一个想法是创建一个通用的“BoxItemTasks”表来定义可以在给定的盒子上完成的任务,但我仍然需要单独保存日期和用户信息,所以它没有真正帮助。

我的第二个想法是,也许这无关紧要,如果这张桌子有40个或更多的专门用于保留国家的话,我不应该担心......也许我只是偏执狂。但感觉就是要保留很多信息。

无论如何,就第三种选择而言,或者上述两种选择中的一种实际上是合理的,我是亏本的。我可以看到这个工作流程在将来可能变得更加复杂,而且对于每个新任务,我需要添加3-4个字段以支持跟踪它...感觉它正在失控。

在这种情况下你会做什么?

我应该注意到这是对现有系统的维护,这是一个没有ORM的系统,所以我不能把它留给ORM来处理它。

编辑:

凯夫,你在谈论做这样的事情:

BoxItems

(PK)BoxItemID

(其他不相关的东西)

BoxItemActions

(PK)BoxItemID

(PK)BoxItemTaskID

IsCompleted

DateCompleted

UserCompleted

BoxItemTasks

(PK)TaskType

描述(如果有必要的话)

嗯...那会起作用...它代表需要改变我目前处理SQL查询的方式,看看哪些项目处于什么状态,但从长远来看,这样的事情看起来会更好(无需像序列化理念那样进行基本的设计更改......但如果我有时间,我想按照我的想法这样做。)。

这就是你提到Kin的原因,还是我关闭它?

编辑:啊,我看到你的想法以及“最后行动”来确定目前的状态......我喜欢它!我认为这可能对我有用......我可能需要稍微改变它(因为在某些时候任务同时发生),但这个想法看起来很好!

EDIT FINAL:所以总结一下,如果其他人在将来用同样的问题来看这个......如果你的系统将信息预先加载到某个界面中,那么序列化方法会很有用可查询(即不直接调用数据库本身,就像我正在处理的ad-hoc系统那样),但是如果你没有这个,那么附加表的想法似乎应该运行良好!谢谢大家的回复!

7 个答案:

答案 0 :(得分:4)

如果我理解正确,我会添加BoxItemTasks表(只是一个枚举表,对吧?),然后是一个BoxItemActions表,其中包含BoxItems和BoxItemTasks的外键,表示它是什么类型的任务。如果你想使特定任务只能在特定的盒子项上执行一次,只需使(Items + Tasks)对列成为BoxItemActions的主键。

(你把它比我做得好得多,并且正确地解释我所说的内容而感到荣幸。你所写的正是我所描绘的。)

至于确定当前状态,您可以在BoxItemActions上编写一个触发器来更新单个BoxItems.LastAction列。对于并发操作,您的触发器可能只有特殊情况来决定哪个操作需要新近度。

答案 1 :(得分:3)

如前面的答案所示,我会把你的桌子分成几个。

BoxItemActions,包含工作流程需要经历的操作列表,每次创建BoxItem时都会创建。在此表中,您可以跟踪每个任务完成时的详细日期\时间\用户。

使用这种类型的应用程序,知道Box下一步的位置可能会非常棘手,因此对Box来说剩下的步骤“Map”将会非常有用。同样,这个表可以像疯了一样分组,每个盒子有数百行,而且它仍然很容易查询。

它还可以实现易于更改的“不同路径”。通过工作流程的“路径”主数据表是一种解决方案,在创建每个框时,用户必须选择框将遵循的“路径”。或者您可以进行设置,以便在用户创建框时,他们选择此特定框所需的任务。取决于我们的业务问题。

答案 2 :(得分:1)

序列化和数据库模型的混合如何。拥有一个用作主工作流文档的XML文档,其中包含每个步骤的节点,其中包含详细说明其名称的属性和元素,流程中的顺序,是否可选的条件等。最重要的是,每个步骤节点都可以具有独特的步骤id。

然后在您的数据库中,您有一个简单的两个表结构。 BoxItems表存储您的基本BoxItem数据。然后一个BoxItemActions表就像你标记为答案的解决方案一样。

它基本上类似于作为答案接受的解决方案,但是使用XML文档而不是用于存储任务主列表的BoxItemTasks表,可以为实际工作流定义提供更多灵活性。

答案 3 :(得分:0)

对于它的价值,在BizTalk中,他们通过二进制序列化将数据库序列化为数据库来“脱水”长时间运行的消息模式(工作流等)。

答案 4 :(得分:0)

我想我会将Workflow对象序列化为XML并使用ID列存储在数据库中。报告可能更难,但听起来它可能适用于您的情况。

答案 5 :(得分:0)

对于这类问题,请考虑http://www.databaseanswers.org/data_models/workflow/index.htm中显示的数据库架构,该架构模拟业务流程中的一系列事件。

答案 6 :(得分:-2)

我建议使用graphdb存储此类流。您可以将BoxItem作为节点之间的顶点存储为Users。 这样,您可以得出以下流程: User1 ----------(BoxItem作为顶点)--------> user2 ....