多数のビジネスルールとプロセスを使用したビジネスロジックの実装
現在、データベースに大きく依存するプロジェクトに取り組んでいます。多くのテーブルの中で、主な焦点は、別のテーブル「data_type」に多対1でリンクされ、次にテーブル「data_operation」に1対多でリンクされるテーブル「data」にあります。
最後のテーブルは、特定のデータ型に基づいてテーブル「data」の各行に対して処理する必要がある特定の操作のセットを定義します。この操作は、テーブル「data」の特定のフィールドと、この例では言及されていない他のテーブルの一部のデータに対して処理されます。実際の操作は、ほとんどの場合、複雑な計算または特定の式です。特定の操作の結果は、さらに別のテーブルに保存されます。
したがって、一般的には次のようになります。
- テーブル「データ」の予測は年間約100万行ですが、他のテーブルは年間ベースで大幅に変更されるべきではありませんが、最初は数千行を保持します。つまり、各データタイプは約10〜15の操作を定義します。
- 各操作は元に戻すことができます（変更を元に戻します）。
- 処理速度は非常に重要な要素です。
- アプリケーションは、おそらく1日あたり2500の新しいテーブル「データ」行を処理します。
私の質問は、操作を実装するための最良のアプローチに関するものです。ビジネスロジックとルールをデータベース（プロシージャ、各操作のトリガー）に移動するか、アプリケーション/ビジネスレイヤーで各操作を実装して処理する方が賢明だと思いますか？理想的な一般的な構造は何でしょうか？
また、他のアプローチについてもオープンです。
幸福感が彼のコメントを回答として投稿しなかった理由はわかりませんが、彼は正しいです。同じデータが多くのユースケースで表示される可能性があり、それはルールに影響を与えます。予想される動作に基づいて、ユースケースごとにビジネスクラスを設計する必要があります。次に、自分が持っているデータを確認し、それを保存する方法を見つけます。
たとえば、部分的な見積もりを保存できる場合があります。ただし、システムが見積もりを顧客に送信できるようになる前に、より多くのデータが必要になる場合があります。見積もりを注文に変換するためのさらに異なるルールなど。
dataテーブルには、いくつかの列があります。列の1つはtypeを保持します。 data_typeテーブルはtypeからキー設定され、名前を追加します。 operationテーブルは、data_typeテーブルのname列をキーとし、action列を追加します。
1）data_typeテーブルのポイントがわかりません。タイプを名前にマッピングしても、このシナリオに実際に価値が追加されるわけではありません。 operationはdataに直接マップする必要があります。
2）action列は、目的のタイプを持つdataテーブルのすべての（新しい）行で実行される操作の名前です。これは単なるマッピングの演習ですか？それとも、新しい種類のアクションを頻繁に追加しますか？
3）オペレーションはどの程度可逆的ですか？単一のdataテーブル行に対するアクションのコレクション全体を意味しますか？個々のアクションは可逆的だということですか？トランザクションの開始/コミットが単一のテーブルの一連のアクションを囲むことを想定していますか？それとも、数分または数日にわたって、より大きな規模でリバーシブルを意味するのですか？
アプリケーション層が最新のオブジェクト指向言語で記述されている場合、 コマンドパターン があります。コマンドパターンの1つの側面は、コマンドに元に戻す操作を追加できることです。
個人的な注意：データベーストリガーがあるときに計算を可逆的にしようとすることは、非常に難しいことです。結果をアプリケーション層に移動すると、データ変更のダウンストリームアクティビティを追跡できるようになり、アクション全体または操作を元に戻せるようになる可能性があります。