11

タスクを処理するための複雑なワークフロー状態をデータベースに格納する方法に関するベスト プラクティスについて質問があります。私はオンラインで探しても無駄だったので、コミュニティに彼らが何が最善だと思うか尋ねてみようと思いました.

この質問は、前の質問で示したのと同じ「BoxItem」の例から出てきます。この「BoxItem」は、さまざまなタスクが実行されているため、システムで追跡されています。タスクは数日にわたって人的介入を伴う場合があるため、BoxItem の状態を永続化する必要があります。誰がタスクを実行したか (該当する場合)、いつタスクを実行したかも追跡する必要があります。

最初に、実行する必要がある人間と対話するタスクごとに「BoxItems」テーブルに 3 つのフィールドを追加することで、これに取り組みました。

TaskName は完了していますか

日付TaskName完了

ユーザーTaskName完了

これは、ワークフローが単純だったときに機能しました...しかし、現在では複雑なプロセスに成長しています (フロー内で可能な人間の相互作用は 10 を超えています...その約半分はオプションであり、BoxItem に対して実行される場合と実行されない場合があります。その結果、これらのオプションのタスクにも「Do TaskName」フィールドを追加し始めました)、単純なテーブルであるべきだったものが、この状態情報の保持に完全に専念する40ほどのフィールドになっていることがわかりました.

もっといい方法はないかと悩んでいますが…困っています。

最初に考えたのは、特定のボックスで実行できるタスクを定義する一般的な「BoxItemTasks」テーブルを作成することでしたが、それでも日付とユーザーの情報を個別に保存する必要があるため、あまり役に立ちませんでした。

私の 2 番目の考えは、おそらくそれは問題ではないということでした。このテーブルに状態保持専用のフィールドが 40 以上あっても心配する必要はありません。しかし、それは保持する情報が多いように感じます。

とにかく、3番目のオプションが何であるか、または上記の2つのオプションのいずれかが実際に合理的であるかどうかについて、私は途方に暮れています. このワークフローは将来さらに複雑になる可能性があり、新しいタスクごとに、追跡をサポートするためだけに 3 ～ 4 つのフィールドを追加する必要があります。

この状況であなたはどうしますか？

これは、ORM を使用せずに構築された既存のシステムの保守であるため、ORM だけに任せることはできません。

編集：

Kev、あなたはこのようなことについて話しているのですか:

ボックスアイテム

(PK) BoxItemID

(その他関係ないもの)

BoxItemActions

(PK) BoxItemID

(PK) BoxItemTaskID

完成されました

完了日

ユーザー完了

BoxItemTasks

(PK) タスクタイプ

説明（必要であれば）

うーん...それはうまくいくでしょう...それは、どのアイテムがどの状態にあるかを確認するためにSQLクエリを実行する現在のアプローチを変更する必要があることを表していますが、長期的には、このようなものがよりうまく機能するように見えます(シリアライゼーションのアイデアが表すような根本的な設計変更を行うこと...時間があれば、そのようにしたいと思います.)

これはあなたがKinについて言及していたことですか、それとも私はそれを理解していませんか?

編集：ああ、現在の状態を判断するための「最後のアクション」についてもあなたのアイデアが見えます...私はそれが好きです! それは私にとってはうまくいくと思います...少し変更する必要があるかもしれません(ある時点でタスクが同時に発生するため)が、アイデアは良いもののようです!

EDIT FINAL：要約すると、将来、誰かが同じ質問でこれを調べている場合...システムに情報がクエリ可能なインターフェースに事前にロードされている場合（つまり、私が取り組んでいるアドホック システムのように、データベース自体を直接呼び出すわけではありません)。ご回答ありがとうございます。

4

5 に答える 5

4

私の理解が正しければ、BoxItemTasks テーブル (単なる列挙テーブルですよね?) を追加してから、BoxItems および BoxItemTasks への外部キーを持つ BoxItemActions テーブルを追加して、タスクの種類を指定します。特定のタスクを特定のボックス アイテムに対して 1 回だけ実行できるようにする場合は、(アイテム + タスク) 列のペアを BoxItemActions の主キーにします。

（あなたは私よりもはるかにうまくレイアウトしており、私の言っていることを正しく解釈したことを称賛します。あなたが書いたものはまさに私が描いていたものです。）

現在の状態を判断するために、単一の列 BoxItems.LastAction を更新するトリガーを BoxItemActions に書き込むことができます。同時アクションの場合、トリガーには、最新のアクションを決定する特別なケースがあります。

于 2008-09-22T19:09:05.627 に答える
3

前の答えが示唆したように、私はあなたのテーブルをいくつかに分割します。

BoxItemActionsは、ワークフローが実行する必要のあるアクションのリストを含み、BoxItemが作成されるたびに作成されます。この表では、各タスクが完了したときの詳細な日付\時間\ユーザーを追跡できます。

このタイプのアプリケーションでは、Boxが次に進む場所を知るのは非常に難しい場合があるため、Boxの残りのステップの「マップ」を用意しておくと非常に役立ちます。同様に、このテーブルは、ボックスごとに数百行という狂ったようにグループ化できますが、それでもクエリは非常に簡単です。

また、簡単に変更できる「異なるパス」を持つことも可能になります。ワークフローを通る「パス」のマスターデータテーブルは1つのソリューションであり、各ボックスが作成されるときに、ユーザーはボックスがたどる「パス」を選択する必要があります。または、ユーザーがボックスを作成するときに、この特定のボックスに必要なタスクを選択するように設定することもできます。私たちのビジネス上の問題によって異なります。

于 2008-09-22T19:23:30.103 に答える
1

シリアライゼーションとデータベース モデルのハイブリッドはどうですか。マスター ワークフロー ドキュメントとして機能する XML ドキュメントを用意します。このドキュメントには、各ステップのノードが含まれており、各ステップの名前、プロセスの順序、オプションかどうかの条件などの詳細を示す属性と要素が含まれています。最も重要なのは、各ステップ ノードに一意のステップ ID。

次に、データベースには単純な 2 つのテーブル構造があります。BoxItems テーブルには、基本的な BoxItem データが格納されます。次に、回答としてマークしたソリューションと同様の BoxItemActions テーブル。

これは基本的に、回答として受け入れられたソリューションと似ていますが、タスクのマスター リストを格納する BoxItemTasks テーブルの代わりに、実際のワークフロー定義の柔軟性を高める XML ドキュメントを使用します。

于 2011-10-10T18:48:12.130 に答える
0

価値があるのは、BizTalk では、実行時間の長いメッセージ パターン (ワークフローなど) をデータベースにバイナリ シリアル化することによって "脱水" することです。

于 2008-09-22T19:00:15.010 に答える
0

Workflow オブジェクトを XML にシリアル化し、ID 列を使用してデータベースに格納すると思います。報告するのはもっと難しいかもしれませんが、あなたの場合はうまくいくようです。

于 2008-09-22T19:03:30.807 に答える