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