現在取り組んでいるスケジュール アプリケーションのデータベース スキーマを設計しようとしています。やり方はあるのですが、ちょっとむずかしそうです。関係する変数のために、これが獣の性質であるかどうか、私は興味があります.
このアプリケーションは求人掲示板に似ていますが、スケジューリング コンポーネントがあります。ジョブ (または「プロジェクト」) を作成してから、勤務日を設定し、そのジョブに対してどのポジションが空いているかを言うことができます。他の人はその仕事にサインアップし、採用されるか拒否されるかのいずれかです。
問題点：
-ジョブは同時実行されないため、2 か月間で 10 日間の作業が発生する可能性があります。
・職種によってポジションが変わります。彼らはリストから選ばれますが、ある仕事には 10 のユニークな募集ポジションがあるかもしれませんし、別の仕事には 5 つのポジションがあるかもしれません。
間違いなく不格好に感じる私の考えは、[jobId、positionName、date]を持つ1つのテーブルとして「openPositions」を持ち、[jobId、positionName、date、acceptFlag]を持つ「jobApply」を持つ2番目のテーブルを持つことです。したがって、各日付には各位置のエントリがあります。明らかに、これは指数関数的に大きくなります (openPositions は [#days * #positions] 行になります)。ポジションにサインアップする人々に毎日対応できるように強制することで、これを減らすことができましたが、スケジュールの柔軟性を考慮したかったのです.
このプロジェクトは全体として、私が取り組んできたものよりも大きなものですが、取り組むことに興奮しています。アイデアがあればぜひ聞きたいです。説明が必要な場合はお知らせください。
編集：抽象度の低いクイック例：
プロジェクト1
実施日： 3/1、3/5、3/6、3/9、4/2、4/5、4/8
必要なポジション:プロジェクト リーダー、プログラマー 1、プログラマー 2、モデラー、レベル デザイナー、インターン
したがって、私の（不格好な）バージョンには、次のように openPositions へのエントリがあります。
(3/1、プロジェクト リーダー)、(3/5、プロジェクト リーダー)、(3/6、プロジェクト リーダー)、(3/1、プログラマー 1) など。
繰り返しになりますが、明らかにこれには多くのエントリが含まれており、これが私の懸念事項です (この場合、7 つの日付 x 6 つの位置なので、データベースには 42 行あります)。これが少し役立つことを願っています。