ベストプラクティス：アイテムのワークフロー状態をデータベースに保存しますか?

Question

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

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

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

はタスク名完了

日付タスク名完了

ユーザータスク名完了

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

もっと良い方法はないのかと自問してしまうのですが…しかし、私は迷っています。

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

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

とにかく、3 番目の選択肢が何なのか、あるいは上記の 2 つの選択肢のうちの 1 つが実際に妥当なのかどうか、私は迷っています。このワークフローは将来さらに複雑になる可能性があり、新しいタスクごとに、タスクの追跡をサポートするために 3 ～ 4 つのフィールドを追加する必要があるでしょう...制御不能になりつつあるように感じます。

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

これは、ORM なしで構築された既存のシステムのメンテナンスであるため、ORM に任せることはできないことに注意してください。

編集：

ケブ、次のようなことをすることについて話しているのですか:

ボックスアイテム

(PK) ボックスアイテムID

(その他関係のない内容)

ボックスアイテムアクション

(PK) ボックスアイテムID

(PK) BoxItemTaskID

完成されました

完了日

ユーザー完了

ボックスアイテムタスク

(PK) タスクタイプ

説明 (必要な場合)

ふーむ...それはうまくいくでしょう...これは、どの項目がどのような状態にあるかを確認するために SQL クエリを実行する現在のアプローチを変更する必要があることを意味しますが、長期的には、このような方法の方がうまく機能しそうです (シリアル化のアイデアのような根本的な設計変更を行う必要はありません) ...を表します時間があれば、そのようにしたいと思いますが。）

それで、これはあなたがキンについて言及したことですか、それとも私がそれを間違っているのですか？

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

最終編集:要約すると、将来、他の誰かが同じ質問でこれを調べている場合...シリアル化アプローチは、システムの情報がクエリ可能なインターフェースに事前に読み込まれている場合 (つまり、私が取り組んでいるアドホック システムのように、データベース自体を直接呼び出すわけではありません)。しかし、それがない場合は、テーブルを追加するというアイデアがうまく機能するはずです。ご回答いただきありがとうございました!

Answer 1

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

(あなたは私よりもはるかに上手に説明してくれました。私の言ったことを正しく解釈してくれてありがとう。あなたが書いたことはまさに私がイメージしていたものです。）

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

Answer 2

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

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

このタイプのアプリケーションでは、Box が次にどこに行くのかを知るのが非常に難しいため、Box の残りの手順の「マップ」を用意しておくと非常に役立ちます。また、このテーブルは、ボックスごとに数百行をグループ化することができ、クエリも非常に簡単です。

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

Answer 3

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

これで、データベースには単純な 2 つのテーブル構造ができました。BoxItems テーブルには、基本的な BoxItem データが保存されます。次に、回答としてマークしたソリューションとよく似た BoxItemActions テーブル。

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

Answer 4

つまり、BizTalk では、長時間実行されるメッセージ パターン (ワークフローなど) をデータベースにバイナリ シリアル化することで「デハイドレート」します。

Answer 5

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

Answer 6

この種の問題については、次のデータベース スキーマを考慮してください。 http://www.databaseanswers.org/data_models/workflow/index.htm これは、業務プロセスにおける一連のイベントをモデル化します。