質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

88.19%

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

解決済

回答 2

投稿

  • 評価
  • クリップ 0
  • VIEW 1,296

Z-TALBO

score 493

やりたいこと

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にも反映させてもいいかなとか思ったのですが、そこらへんは使ってみて欲しいかどうかで判断します。

最後に

長くなってしまい、質問として適切なのか?という判断もついておりません。。。
不適切な場合等ありましたらご指摘ください。

正規化などのことを見てみたりしていますが、見てやるだけだと、最終的にこれはどうなんだろう??と考えてしまいますので、こちらで質問させていただき、ご指摘いただければより理解ができるものと考えました。

よろしくお願い致します。

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 過去に投稿した質問と同じ内容の質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 2

checkベストアンサー

0

分けて考える方のテーブル設計のほうが良いと思います。

一台の車に乗車できるスタッフが3名までという制限は、プログラム側でかけたほうが例えばマイクロバスを使う場合が追加されたなどで選択した車によって同乗するスタッフのが数が変わるなど、複雑な要件に対応するのには便利です。テーブル設計での制約をかけるべき内容もありますが、繰り返し項目の増減はかなり変更負荷が大きいので避けるべきです。

と言いつつ、messageの項目に関しては、Recordに追加しても問題ないかなぁ。というのも単体で呼び出す必要が考えられないので、XMLやJsonで繰り返し項目として定義しても支障が出ないかなとも思います。しかし万が一、個別にあつかう必要が出たときは、ちょっと大変なことになります。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2016/05/30 08:39

    回答ありがとうございます!

    分けて考えれる、分けてやっていけるなら分けたほうがいいですかね。
    確かに制限などはプログラム側でやったほうがやりやすそうですしね。。。

    規模的にそこまで複雑なことをするわけではないのですが、別のマスターを作った時にこのカラムは別でテーブル作ろうとした時、確かにありゃりゃなことになったので、今回は分けて考えていくようにしてみたいと思います。

    キャンセル

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/30 08:35

    回答ありがとうございます。
    予定と実績での1:??の違いによって考えを変えていったら良いんですね。

    参考になりました!

    キャンセル

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 88.19%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

関連した質問

同じタグがついた質問を見る