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