質問: ### やりたいこと DBの設計において、どれが正解というものも無いかとは思いますが、今現在私が考えていることに対してアドバイスや、ご指摘をいただければと思います。 ### 一連の流れについて 現在、考えているものをおおまかではありますがご説明いたします。 ※シチュエーション?としては、訪問系(介護)の仕事において、訪問予定の登録、その訪問後の実際の訪問実績の登録ということを想定しております。 条件等 ->訪問先は1日に何件かありますが、登録は利用者1人ずつでの登録をしていきます。 ->訪問先1件につき、訪問するスタッフは基本3人ですが1~3の間で動的です。 ->訪問時間は基本1時間(予定の場合)とします。 その他 ->今回はDBの設計についての質問としますので、動作的な部分はとりあえず考えておりません。 「スタッフの動き」 1.スタッフA(基本的に登録などをするスタッフは代表一名が行う)は、本日乗車する車の登録をする ↓ 2.スタッフAはその次に訪問予定の登録として、 ・利用者の選択 ・スタッフAの選択 ・スタッフBの選択 ・スタッフCの選択 ・訪問予定時間の選択 上記の選択を行った後に登録をする。 2の動きを本日訪問する件数分行っていく。 ※この時スタッフAに関しては動くことはありませんが、BとCは別のスタッフになる可能性(乗換)があります。 予定の登録というだけに着目すると動き方としてはこれだけで良いと思いますので、この内容からDBの方を考えてみたいと思います。 ### DBについて 現在いくつかのテーブルは作成しておりますが、、、 まず、上記で選択している部分のそれぞれのテーブルが必要かなと思いました。 ``` [car_master] car_id, car_name [user_master] user_id, user_name [staff_master] staff_id, staff_name ``` 他にもカラムは考えていますが、今回はとりあえずこれだけで見ていけばいいかなと思います(予定では使わない情報もあるから)。 さて、次に訪問予定というテーブルを考えました ``` [visitplan] plan_id int not null auto_increment primary key, car, // 乗車する車 user, // 訪問先 staff_A, // staffA staff_B, // staffB staff_C, // staffC visittime // 日時('2016-05-28 13:30:00')->例です ``` 別に、これで良いんじゃないかと思うのですが、、、先ほどチラッと記載したようにスタッフに関しては3人かもしれないし、2人かもしれないし、1人かもしれない、、、という部分でそうなると、データに空白?が生れることになるので、どうなのかな?とまず思いました。 そこで、下記のことも考えてみました ``` // userのplanはそれだけで登録する [visitplan_user] plan_id int not null primary key, user, visittime // staffのplanとして登録する [visitplan_staff] plan_id, staff_id // carplan [visitplan_car] plan_id, car_id ``` Plan_idで紐付けというのでしょうか?それで同一行のデータであるとし、一覧表示のようであれば、くっつけてくっつけてという感じで表示はできるかなと思ったのですが、当然上記程度のテスト用の小規模データであれば、先に記載したvisitplanのテーブルだけで考えたほうがいいのかもしれませんが、、、 plan_idなどは、表示させる側の動かし方で動的に生成させれればいいのかなと思いました。auto_incrementだとずれると思ったので。 ### 一連の流れについて(訪問実績) さて、ここまでは訪問予定に関しての今考えてみた部分を記載しましたが、予定があれば実績もあるということでここからは実績の部分で考えてみたいと思います。 基本的な動きはさほど変わったりするものではないのですが、、、 「スタッフの動き」 1.登録された予定表を表示させる(1人分でも1日でもそれは後考えます) ↓ 2.訪問時に打刻ボタンで打刻する(入力でもいいのですが、訪問介護などのシステムなどでそういうのが発売されていたと思うのでそういうイメージです) ↓ 3.訪問終了後に打刻ボタンで打刻する ※2と3をすることで実際の訪問にかかった時間などがわかるようになる。 ↓ 4.訪問した中で行ったサービスの選択 ※内容は基本的に決まったことです。 ↓ 5.利用料の徴収などに関しての選択 ↓ 6.その他伝言などのことがある場合入力 今考えてる動きとしてはこのような感じかな?と思っています。 ※今後当然変更もあるでしょうが、、、、 ### DBについて(実績) まずは、予定のテーブルと同様にたった一つだけのテーブルという考え方をしました。 ``` [visitrecord] record_id, visit_start datetime, visit_exit datetime, staff_A, staff_B, staff_C, visit_car, service, peyment, message ``` やはり、これだとなんかダメなのかな?って感じがありますので、予定と同じように分けて分けて考えてみました ``` [visitrecord_user] record_id, user, visit_start, visit_exit, [visitrecord_staff] record_id, staff [visitrecord_car] record_id, car [visitrecord_service] record_id, service [visitrecord_peyment] record_id, peyment [visitrecord_message] record_id, message ``` ただただ、分けるとなればこの様にもできるかなと思い記載してみました。 ### 補足など まず、serviceに関してはplan側にはありません。これは、基本的に行うserviceがすでに決まっており、種類も無いので入れておりませんが、recordの方では訪問が中止になったなどのことが考えられるので、recordの方にだけあります。 peymentやmessageの部分に関しても同様の考え方です。 messageの部分はplanにも反映させてもいいかなとか思ったのですが、そこらへんは使ってみて欲しいかどうかで判断します。 ### 最後に 長くなってしまい、質問として適切なのか?という判断もついておりません。。。 不適切な場合等ありましたらご指摘ください。 正規化などのことを見てみたりしていますが、見てやるだけだと、最終的にこれはどうなんだろう??と考えてしまいますので、こちらで質問させていただき、ご指摘いただければより理解ができるものと考えました。 よろしくお願い致します。
回答: 分けて考える方のテーブル設計のほうが良いと思います。 一台の車に乗車できるスタッフが3名までという制限は、プログラム側でかけたほうが例えばマイクロバスを使う場合が追加されたなどで選択した車によって同乗するスタッフのが数が変わるなど、複雑な要件に対応するのには便利です。テーブル設計での制約をかけるべき内容もありますが、繰り返し項目の増減はかなり変更負荷が大きいので避けるべきです。 と言いつつ、messageの項目に関しては、Recordに追加しても問題ないかなぁ。というのも単体で呼び出す必要が考えられないので、XMLやJsonで繰り返し項目として定義しても支障が出ないかなとも思います。しかし万が一、個別にあつかう必要が出たときは、ちょっと大変なことになります。