0

注文明細を含む注文があり、さまざまなユーザーが注文明細を追加できるマルチユーザー システムがあるとします。注文はデータベースに保持されます

ビジネス ルールの 1 つは、1 つの注文に対して 10 の注文明細行しか作成できないというものです。

このルールが破られていないことを確認するためのオプションは何ですか? メモリをチェックインしてロックを適用する必要がありますか、それともプロシージャを介してデータベースでこれを処理する必要がありますか?

4

2 に答える 2

2

これを処理する方法には、トリガー、制約、ビジネス ルール ロジック、データ構造など、さまざまなオプションがあります。

私の好みは以下です。すべての挿入/削除/更新をストアド プロシージャ内のオーダーラインにラップし、ストアド プロシージャを介してのみアプリケーション層にテーブルへのアクセスを許可します。このプロシージャは、このビジネス ルールおよびその他のビジネス ルールを適用できます。また、実行中に更新のためにテーブルをロックするため、特定の瞬間にテーブルを変更できるのは 1 人のユーザーだけです。

同様のアプローチは、テーブルに挿入の代わりにトリガーを設定することです。これにより、この (および他の) ビジネス ルールが失敗したときに挿入が失敗します。これに関する主な懸念事項は、保守性です。1 つのテーブルに 1 つのトリガーで十分です。ただし、カスケード挿入/削除を使用して複数のテーブルに対してこれを開始すると、トリガーの悪夢に終わる可能性があります。

コメントの1つが示唆しているように、制約を付けてこれを試みることができます。制約の実装方法をほとんど制御できないため、パフォーマンスについてこれをテストすることをお勧めします。

また、order テーブルに 10 個の orderline 列を含めることもできます。これにより、このルールが強調されます。ただし、注文明細行ごとに個別の列を用意し、削除などの問題に対処しなければならないというコストがかかります。

この場合には適切ではない別のオプションは、アプリケーション レベルでビジネス ルールを適用することです。ただし、複数の同時ユーザーがいる場合は、データベースでこの作業を行う必要があります。

于 2012-06-27T13:28:26.540 に答える
1

最悪の場合、多数の（つまり2を超える）ユーザーがすべて同時に1つの注文に行を追加しようとしていると仮定します。（さらに悪いことに、一度に10を超えることはありませんが、すべてがさまざまな数の行を追加しようとしていると仮定します。GUIは少なくともその量を制御できます）。これにより、次のようなシナリオが発生します。

  • 小切手は彼女の列のためのスペースがあります、大丈夫です
  • Bは彼の列のためのスペースがあるかどうかをチェックし、大丈夫になります
  • Aは彼女の列を追加します、人生は良いです
  • Bは行を追加し、現在11行あります
  • これらはすべて、10分の1秒以内に行われました。

これを回避するには、すべてのユーザーが行を追加できるかどうかを判断するための、何らかの形式の中央「チェックポイント」またはレギュレーターが必要です。チェックポイントに合格すると、追加できます。合格しない場合、彼らは合格できません。チェックポイントは絶対的である必要があります。承認が受信/割り当てられると、その決定は後続のすべてのチェックに影響します（つまり、チェックして10行目が付与された場合、以前は誰もそれを付与されておらず、その後は誰もそれを付与されません）。 。

これを実装する方法はいくつかあり、それらはすべてデータベーストランザクション（ACIDプロパティ）を含みます。他のユーザーとのブロックやデッドロックを回避するために、トランザクションは常に可能な限り短くする必要があります。これはトリッキーなコードになる可能性があり、私のお金では、プロセスを実装/制御するための最良の方法は、ストアドプロシージャを使用することです（@Gordon Linoffが言ったように）。

于 2012-06-27T13:40:46.457 に答える