私はテーブルのセットを設計するのが新鮮で、その中で私は非常に満足しているアーキテクチャを思いついたのです！私はこれまでどこにも見たことがないので、車輪の再発明をしたばかりなのか（おそらく）、これが真の革新なのかを知りたいと思います。
問題の説明は次のとおりですEmployees。会社とはそれぞれ異なる契約を結ぶことができる人がいます。各従業員は異なる活動を実行でき、各活動は異なる賃金率、時には1つの活動を完了するための固定額、時には時間給、時には段階的率を持っているかもしれません。また、その従業員を特に気に入っている特定の顧客がいる可能性があるため、その特定の顧客と一緒に仕事をすると、彼はより高いレートを取得します。また、レートが定義されていない場合、彼は会社のデフォルトレートを取得します。
詳細については気にしないでください。重要な点は、定義できる支払いレートがたくさんあり、それぞれがかなり複雑な方法であるということです。そして、賃金率にはすべて共通点があります。
- サービスの種類
- 賃金表タイプ（列挙型：固定金額/時給/ティアードレート）
- 固定金額（PayScaleType = FAの場合）
- 時給（PayScaleType = HRの場合）-はい、1つのフィールドにマージできますが、ここでは説明しないため、これらを別々に保持しました
- ティア（1-> nの関係、すべてのティアと、ティアのしきい値を超えたときに支払う金額）
これらの支払い率は以下に適用されます。
- デフォルトの会社レート
- 従業員率
- 従業員のオーバーライド率（顧客ごとに定義）
単純なブルートフォースアプローチに従う必要がある場合は、上記の3つのテーブルのそれぞれに、対応するLinqクラスに加えて、3つの別々の場所でレートを計算するロジックを作成しPayRate、クローンテーブルを作成する必要があります。PayRateTier計算ロジック。うーん。これは、データベース上でコピーアンドペーストを使用するようなものです。
代わりに、私は何をしましたか？PayRatePackageIDフィールドのみで構成される中間テーブルを作成しました。に必須のFKを持つテーブルと、に必須のFKを持つテーブルが1つだけあり ます。次に、doおよび。と同様に、必須のFKがあります。PayRatePayRatePackagePayRateTierPayRateDefaultCompanyPayRatePayRatePackageEmployeeRateEmployeeOverrideRate
とてもシンプルです-そしてそれは機能します！
（図を添付しないことをお詫びします。それは、私がすでに主要な問題を解決しているSOの質問に行くのに多大な労力を要します。多くの人が図を見たい場合は、コメントでそう言ってください。一緒に何かを投げます。）
さて、このシンプルで効果的なものは、どこかでフォーマルなデザインパターンになっているはずだと確信しています。それが何であるかを知りたいです。それとも私は何か新しいものを発明したのですか？:)