4

私は、データベースに保存されている大勢の人々の特定のタイプのステータスを判別する必要があるプロジェクトに取り組んでいます。これらのステータスを決定するためのビジネスルールはかなり複雑であり、変更される可能性があります。

例えば、

if a person is part of group X 
and (if they have attribute O) has either attribute P or attribute Q, 
or (if they don't have attribute O) has attribute P but not Q,
and don't have attribute R, 
and aren't part of group Y (unless they also are part of group Z), 
then status A is true.

数十のステータスと、場合によっては数百のグループと属性を掛けます。人、グループ、および属性はすべてデータベースにあります。

これはJavaアプリによって消費されますが、データベースに対して直接レポートを実行できるようにすることも必要なので、計算されたステータスのセットがデータレベルで利用可能であることが最善です。

したがって、現在の設計計画では、各人のブールフラグのセット（hasStatusA？hasStatusB？hasStatusC？）で構成されるテーブルまたはビューを作成します。このように、ステータスCを持つすべての人にクエリを実行する場合、ステータスCを計算するためのすべてのルールを知る必要はありません。旗をチェックするだけです。

（実際には、フラグにはより意味のある名前が付けられることに注意してください：isEligibleForReview？、isPastDueForReview？など）。

したがって、a）これは合理的なアプローチであり、b）もしそうなら、それらのフラグを計算するための最良の方法は何ですか？

フラグを計算するために検討しているいくつかのオプション：

  1. フラグのセットをビューにし、SQLまたはPL-SQL（これはOracle DB）を使用して、基礎となるデータからリアルタイムでフラグ値を計算します。このように、値は常に正確ですが、パフォーマンスが低下する可能性があり、開発者がルールを維持する必要があります。

  2. フラグのセットを静的データで構成し、ある種のルールエンジンを使用して、基になるデータが変更されたときにそれらのフラグを最新の状態に保ちます。このようにして、ルールをより簡単に維持できますが、特定の時点でフラグが不正確になる可能性があります。（このアプローチを採用する場合、この方法でデータベース内のデータを簡単に操作できるルールエンジンはありますか？）

4

3 に答える 3

2

このような場合、ウォード・カニンガムの質問を適用することをお勧めします-「おそらく機能する可能性のある最も単純なものは何ですか？」

この場合、最も簡単なことは、存在するデータを確認し、計算と計算を行って、関心のあるすべてのフィールドを生成するビューを考え出すことです。次に、データベースをロードして試してみます。十分速いですか？もしそうなら、良い-あなたは可能な限り単純なことをしました、そしてそれはうまくいきました。十分に速くない場合は、良いです-最初の試みは機能しませんでしたが、ビューコードにルールがマップされています。これで、「最も単純なこと」の次の反復を試すことができます。おそらく、挿入と更新を監視し、次にジャンプしてフラグを再計算するバックグラウンドタスクを作成します。それがうまくいけば、元気でダンディです。そうでない場合は、次の反復に進みます...など。

共有してお楽しみください。

于 2010-10-06T18:56:32.887 に答える
0

ステータスを列名にするのではなく、ステータスIDと値を使用することをお勧めします。IDと値の列を持つ顧客ステータステーブルなど。

ステータスを更新するには2つの方法があります。すべてのロジックを持っているか、個別のストアドプロシージャを呼び出して各ステータスを把握するストアドプロシージャの1つ。各ステータス評価用の関数を使用することで、このすべてを動的にすることができ、1つのストアドプロシージャが各関数を呼び出すことができます。2番目の方法は、ユーザー情報を更新するストアドプロシージャを用意し、ストアドプロシージャを呼び出して、現在のデータに基づいてすべてのユーザーステータスを更新することです。これらの2つのメソッドを使用すると、変更されたデータをリアルタイムで更新でき、新しいステータスを追加した場合は、メソッドを呼び出してすべてのステータスを新しいロジックで更新できます。

うまくいけば、ユーザー更新ストアドプロシージャなど、ユーザーデータの更新ポイントが1つあり、そのプロシージャにステータス更新ストアドプロシージャ呼び出しを含めることができます。これにより、ステータスを更新するためにn秒ごとにタスクをスケジュールする必要もなくなります。

于 2010-10-06T19:11:56.233 に答える
0

私が検討するオプションは、各フラグが、関連データを指定して最新の値を返す決定論的関数によって裏付けられることです。

ただし、一度に多数の行に対して関数を呼び出す場合（レポートなど）、関数は十分に機能しない可能性があります。したがって、Oracle 11gを使用している場合は、関数に基づいて関連するテーブルに仮想列を追加する（「仮想列」を検索する）ことでこれを解決できます。結果キャッシュ機能により、関数のパフォーマンスも向上するはずです。

于 2010-10-07T00:12:19.417 に答える