MySQL DBの設計について（訪問予定、訪問実績）

###やりたいこと
DBの設計において、どれが正解というものも無いかとは思いますが、今現在私が考えていることに対してアドバイスや、ご指摘をいただければと思います。

###一連の流れについて
現在、考えているものをおおまかではありますがご説明いたします。
※シチュエーション？としては、訪問系（介護）の仕事において、訪問予定の登録、その訪問後の実際の訪問実績の登録ということを想定しております。

条件等
->訪問先は１日に何件かありますが、登録は利用者１人ずつでの登録をしていきます。
->訪問先１件につき、訪問するスタッフは基本３人ですが１～３の間で動的です。
->訪問時間は基本１時間（予定の場合）とします。

その他
->今回はDBの設計についての質問としますので、動作的な部分はとりあえず考えておりません。

「スタッフの動き」
１．スタッフA（基本的に登録などをするスタッフは代表一名が行う）は、本日乗車する車の登録をする
↓
２．スタッフAはその次に訪問予定の登録として、
・利用者の選択
・スタッフAの選択
・スタッフBの選択
・スタッフCの選択
・訪問予定時間の選択
上記の選択を行った後に登録をする。
２の動きを本日訪問する件数分行っていく。
※この時スタッフAに関しては動くことはありませんが、BとCは別のスタッフになる可能性（乗換）があります。

予定の登録というだけに着目すると動き方としてはこれだけで良いと思いますので、この内容からDBの方を考えてみたいと思います。

###DBについて
現在いくつかのテーブルは作成しておりますが、、、
まず、上記で選択している部分のそれぞれのテーブルが必要かなと思いました。

MySQL
[car_master]
car_id, car_name

[user_master]
user_id, user_name

[staff_master]
staff_id, staff_name

他にもカラムは考えていますが、今回はとりあえずこれだけで見ていけばいいかなと思います（予定では使わない情報もあるから）。

さて、次に訪問予定というテーブルを考えました

MySQL
[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')->例です

別に、これで良いんじゃないかと思うのですが、、、先ほどチラッと記載したようにスタッフに関しては３人かもしれないし、２人かもしれないし、１人かもしれない、、、という部分でそうなると、データに空白？が生れることになるので、どうなのかな？とまず思いました。

そこで、下記のことも考えてみました

MySQL
// 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だとずれると思ったので。

###一連の流れについて（訪問実績）
さて、ここまでは訪問予定に関しての今考えてみた部分を記載しましたが、予定があれば実績もあるということでここからは実績の部分で考えてみたいと思います。

基本的な動きはさほど変わったりするものではないのですが、、、
「スタッフの動き」
１．登録された予定表を表示させる（１人分でも１日でもそれは後考えます）
↓
２．訪問時に打刻ボタンで打刻する（入力でもいいのですが、訪問介護などのシステムなどでそういうのが発売されていたと思うのでそういうイメージです）
↓
３．訪問終了後に打刻ボタンで打刻する
※２と３をすることで実際の訪問にかかった時間などがわかるようになる。
↓
４．訪問した中で行ったサービスの選択
※内容は基本的に決まったことです。
↓
５．利用料の徴収などに関しての選択
↓
６．その他伝言などのことがある場合入力

今考えてる動きとしてはこのような感じかな？と思っています。
※今後当然変更もあるでしょうが、、、、

###DBについて（実績）
まずは、予定のテーブルと同様にたった一つだけのテーブルという考え方をしました。

MySQL
[visitrecord]
record_id,
visit_start datetime,
visit_exit datetime,
staff_A,
staff_B,
staff_C,
visit_car,
service,
peyment,
message

やはり、これだとなんかダメなのかな？って感じがありますので、予定と同じように分けて分けて考えてみました

MySQL
[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