クライアント向けの給与生成システムを設計しています。
対象とする組織には、会社->クラスター->ビジネスユニット（BU）->部門->従業員の階層があります。
従業員の給与は、さまざまな給与要素で構成されています。各給与コンポーネントには、計算ルール（コンポーネントを別のコンポーネントの％、または固定数または固定数の％として計算）、適格性ルール（従業員/部門がコンポーネントに適格かどうか）の3つのルールが関連付けられています。コンポーネントの最大値と最小値を制限する制約ルール。
これらのルールは編集可能であり、ユーザーエンドユーザーが編集できます。また、これらのルールはトップダウンで継承されますが、下位レベルで定義されている場合は、下位レベルのルールが優先されます。
Attendance、Leaves、Bonusesテーブルを含むデータベースがあり、これらのルールもこれらのテーブルと相互作用することになっています。
クライアントは、それぞれが個別のデータベースインスタンスをホストしている複数のクライアントの給与を生成します。それらはそれぞれ、各コンポーネントの異なる解釈を持っている可能性があり、異なるコンポーネントを持っている可能性があります。
SQL Serverのサポートのみを検討しており、給与の生成はオフラインアクティビティになります。
これらのルールを使用して個々の税コンポーネント（税控除、税控除、手当などを含む）を生成するロジックをどこに配置するかによって異なります。
一部の人々は、従業員IDを取得し、その月の給与を生成するマジックSPを提唱しています。他の人は、ロジックを個別のコンポーネントに分割して、アプリケーション層の従業員の依存データを取得し、そこでこれらのコンポーネントを計算することを望んでいます。
優先順位は次のとおりです。1。新しいクライアントに変更を迅速に適応させる機能2.長期的な保守性3.パフォーマンス
これはオフラインアクティビティになるため、ここでは1と2が3を大きく上回っています。
保守性と迅速なカスタマイズ性は非常に重要です。さまざまなクライアントにアプリケーションを展開します。クライアントAは（（0.3 *基本）+ 800）として給与コンポーネントルールを持ち、クライアントBは（0.2 *基本）+（0.1 *出席ボーナス）として持つことができます。
上記で提案されたルールはエンドユーザーによって指定され、Web UIを介してカスタマイズ可能である必要があるため、SPはここで混乱を引き起こしますか？SQLから数式を解析する必要があります。それはどれほど難しいか簡単ですか？アプリケーション層（C＃.Net）でこれを行うと、SPを使用するよりもどのような利点がありますか？
既存のシステムのアーキテクチャへの提案とポインタは非常に役立ちます。...はい、システムの他の場所でLINQtoSQLを使用しています。
よろしく、アシシュシャルマ