質問: 来月から社会人エンジニアになることもあり、DBの論理設計のトレーニングをしています。 求人サービスの作成を仮定して論理設計をしているのですが、迷っていることがあります。 以下の様な5つのテーブルがあるとします。 ###### 会社(求人元)テーブル * id * 名前 ###### ユーザー(一般)テーブル * id * 名前 * ###### 仕事テーブル * id * 会社id(fk) ###### 応募者テーブル * id * 仕事テーブルid(fk) * ユーザーid(fk) ###### 仕事成約テーブル * id * 応募者テーブルid(FK) 一般ユーザーと求人元が存在し、会社は仕事(レコード)を作ることができるとします。 その仕事は採用人数が決まっていて、応募ボタン等をユーザーが押すと、応募者テーブルにその仕事の応募したユーザーが追加されます。 つまり応募者テーブルはユーザーと仕事の中間テーブルのようなものになっていると思います。 そして応募者の中から会社は気に入った人材を採用する為、これもボタン等を押すことで仕事成約(レコード)を作成を出来ることにします。(仕事状態等のマスターテーブルは省いています) ここで質問なのですが、応募者テーブルと仕事成約テーブルのリレーションはどうするべきなのでしょうか? 仕事成約テーブルは応募者テーブルから、仕事、会社テーブルを参照出来るため応募者テーブルに対してリレーションを張るべきなのは何となく想像付くのですが、それが1:Nなのか1:1なのかが分かりません。 1つの応募者レコードは多数の仕事成約テーブルを持ち得るかというとそうでは無いと(感覚的に)思っています。 ユニークな仕事テーブルid属性とこれまたユニークなユーザーidを持つ候補者テーブルの1レコードが多数の仕事成約成約を持つとは考えづらいです。 では1:1なのかなと思いますが、1:1テーブルはあまり作らない方がいいと目にしました(カラム数が大量になったり、オブジェクト指向的に良くない場合を除きと目にしました) 改めて応募者テーブルと仕事成約テーブルのリレーションはどうするべきなのでしょうか? 長くなりましたがよろしくお願い致します。
回答: サンプルデータと検索・集計したい結果があるとわかりやすいと思います * 仕事テーブルとユーザーテーブルを応募者テーブルを中間テーブルにして紐づけ * 仕事テーブルには会社テーブルがマスターデータで存在する までは一般的ですね 仕事成約テーブルは、応募者テーブルのフラグでよいような気がします