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

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

新規登録して質問してみよう
ただいま回答率
85.50%
MySQL

MySQL(マイエスキューエル)は、TCX DataKonsultAB社などが開発するRDBMS(リレーショナルデータベースの管理システム)です。世界で最も人気の高いシステムで、オープンソースで開発されています。MySQLデータベースサーバは、高速性と信頼性があり、Linux、UNIX、Windowsなどの複数のプラットフォームで動作することができます。

PHP

PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。

Q&A

解決済

9回答

5220閲覧

DBの設計に関して

Z-TALBO

総合スコア525

MySQL

MySQL(マイエスキューエル)は、TCX DataKonsultAB社などが開発するRDBMS(リレーショナルデータベースの管理システム)です。世界で最も人気の高いシステムで、オープンソースで開発されています。MySQLデータベースサーバは、高速性と信頼性があり、Linux、UNIX、Windowsなどの複数のプラットフォームで動作することができます。

PHP

PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。

3グッド

5クリップ

投稿2016/03/15 10:05

編集2016/03/17 23:39

訪問予定を登録していくのに、DBの設計をどのように作るとわかりやすいものか?と思っているので、アドバイスだけでもいただければと思っています。

1.訪問予定日の選択

2.乗車予定の車の選択

3.乗車予定スタッフの選択(必ず三名乗車)

4.訪問予定先の登録(最小1名~最大10名)

5.訪問予定時刻の登録(4同様)

6.一言コメント用

上記のような予定を登録するフォームをズラズラと作ったとすると、、、

DBの設計としては、、、
tablename=test
1.id,
2.scheduled_date datetime,
3.ride_car,
4.ride_staff_A,
5.ride_staff_B,
6.ride_staff_C,
7.visited_1,
8.visited_sceduled_date_1 datetime,
9.visited_2,
10.visited_sceduled_date_2 datetime,
11.visited_3,
12.visited_sceduled_date_3 datetime,
13.visited_4,
14.visited_sceduled_date_4 datetime,
15.visited_5,
16.visited_sceduled_date_5 datetime,
17.visited_6,
18.visited_sceduled_date_6 datetime,
19.visited_7,
20.visited_sceduled_date_7 datetime,
21.visited_8,
22.visited_sceduled_date_8 datetime,
23.visited_9,
24.visited_sceduled_date_9 datetime,
25.visited_10,
26.visited_sceduled_date_10 datetime,
27.comment text

やはり、それだけの入れる場所がひつようなので、こんなにカラムを作る必要がありますか?

登録する内容は○月○日の○号車には○と○と○が乗って、○に○時~○に○時~・・・というように登録したいのですが。

まずDBを作るのに、こんなにしないといけないものかな~~~と思いつつ、、、

別にこれで行くなら、全然それでいいんですが、こううまくシンプルにできる方法があるのかな?と思ったので質問いたしました。

不適切であれば、申し訳ありません。。。。。


[追記]
回答いただいた方々、本当にありがとうございます!
実は、このような質問は適切なのかどうか?不安でしたが、沢山の回答をいただき、とても参考になっています!

今一度、自分の中で設計図を考え、何をしたいのか?どのようにしたいのか?などを考え直していこうと思っております。


[追記]
こちらは、一応参考までに、、、
現在、会社で使っているエクセルでの運行予定と、業務日誌があります。
ふと、考えたのが運行予定を予定として登録しておいて、予定の車が、予定通り訪問したのか?訪問しなかったのか?などをなんらかのフォームで登録したりすることで、ついでに業務日誌としての表示も済ませてしまう、、、
漠然とではありますが、そんなことができれば楽だな、、、と思ってしまいました。

必要な画面として今考えれるのは、、、、
○運行予定を登録する
×月×日の×号車の予定=スタッフ▲と▲と▲が▲時に▲さんへ→複数
これは、逆に訪問先▲さんの予定として=×月×日は×号車にスタッフ▲さんと▲さんと▲さんが▲時に来るでも良いかもしれませんね。
もしかしたら、スタッフ側で、▲さん=×月×日は×号車にスタッフ▲さんと▲さんと乗り、▲時に訪問先▲さんへ行くという見方もあります。

○運行予定を表示する
号車が複数であり、全体を表示したいのならば→×月×日の予定で検索し、号車別に表示
自分の号車の予定だけならば→×月×日の×号車の予定で検索し、×号車の一日の予定を表示
スタッフ1人別での検索、、、これは実際必要無いと思っています。
訪問先別での検索→訪問先×の一ヶ月分、一週間分、今日の予定での表示

○実績を登録する
例えば、上記での予定の検索において、自分の当日の号車予定を検索し、抽出しておいたとして、
1.9時~ ××さん 訪問 中止 その他のようにボタンを設置しておいて、実際の実績として登録できるようにする。
2.タイムカードのような仕組みで、訪問先に到着した時に訪問先の名前を選択して、訪問と打刻、退室時に退室と打刻することで、訪問時間を実績として登録(実際に訪問した時間)。
3.休憩時間なども、入力できるようにしておく。

○実績の表示、集計
これはほぼ、訪問先別の一ヶ月分の実績を集計して、表示させることになるかなと思っています。

もう、一つずつ作っていって、これが足りない、これはいらないなどを見つけていこうとは思っております。


[追記]
新規で質問しなおすのが適切でしたら、ご指摘ください。
とりあえず元の内容があるので、こちらに追記として、、、、

DBの設計をいろいろ見ながら考えておりますが、、、
上記質問時の予定登録の部分をまず見つめなおしました。
第一正規というのをやってみる際に、上記の流れのままやっていくのも良かったのですが、回答にてご指摘をいただいたとおり、1番に予定日が来て、、、ではなく、訪問先から見ていけば確かに良いんじゃないか?と思いましたので、

MySQL

1tablename = plans // 予定を入れるテーブル 2id // とりあえずこのテーブルのIDは入れておいたほうが良いのかな? 3user_name // 訪問先 4staff_name // 訪問予定スタッフ(A) 5car_number // 訪問予定社用車 6visit_time // 訪問予定日

まずは、こうするだけでシンプルになったかな?と思ったのですが、どうでしょうか?
staff_nameに関しては基本的に訪問は1台の車で訪問先1件に対して3人ですが、確かに2人の場合や、1人の場合があると思ったので、上記のテーブルで考えると、、、

id = 1, user_name = '○○さん', staff_name = '○○', car_number = '○○', visit_time = '2016/03/18 10:00:00' id = 2, user_name = '○○さん', staff_name = '××', car_number = '○○', visit_time = '2016/03/18 10:00:00' id = 3, user_name = '○○さん', staff_name = '▲▲', car_number = '○○', visit_time = '2016/03/18 10:00:00'

1件の訪問先に対して、3名の職員が、○○号車に乗っていつ行くかというデータが3行で作成されました。

こういう感じ自体はいかがでしょうか?

こう考えると、とりあえずstaff, car, userのマスタを作っておけばさらに良いのかな?と考えました。

予定を表示する際も、visit_timeとcar_numberで抽出や、user_nameでの抽出、staff_nameでの抽出も可能かな?と思ったのですが、、、

さらに、実績用のテーブルを作成します。

MySQL

1id 2user_name // 訪問先 3staff_name // 実際訪問した人 4car_number // 実際訪問した社用車 5visit_time // 実際訪問した時間 6service // 訪問した際に何したか 7comment // 一言あれば

こういう感じの見通しはどうでしょう?

lib, thesecret11, yodel👍を押しています

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

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

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

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答9

0

データを同じテーブルに横持ちにするか、
別テーブルにして縦持ちにするかというのは、良く悩むところです。

画面にどう表示したいのか?どういう集計をする必要があるのか?
などがDB設計のインプットになります。

横持ちのメリットはなんといっても、データの取得のしやすさです。
取得結果がそのまま画面の表示に当てはまるのであれば、画面表示も楽になります。

デメリットは仕様変更に劇的に弱いです。
何かあるたびに、列を増やしたり減らしたりする必要があります。

縦持ちのメリット・デメリットは逆ですね。
仕様変更には強いが、取得がめんどくさい(たくさんJOINしたりする必要があるため)。

今回考える余地があるのは、3、4、5です。
A、B、Cや連番などのを持つ列というのは、別テーブル(縦持ち)にした方がいいかもしれません。
その方が仕様の変更に強いからです。

例えば、予定先が10名から20名に増えた場合どうします?
同じテーブルで横持ちに1~10まで持っている場合、11~20まで列を増やす必要があります。
別テーブルにしていれば、テーブルに変更を加えずに対応できます。
そのテーブルのレコード数が増えるだけだからです。

もう仕様が変わることはありません!って言うならば、横持ちでもいいと思います。

投稿2016/03/15 10:40

root_jp

総合スコア4666

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

Z-TALBO

2016/03/16 08:54

メリット、デメリットに関して、コメント頂いたのを読んでみて、、、 確かに!というぐらいの初心者で申し訳ありません。。。。 いままで一つのテーブルで取り回してきて、複数のテーブルに対しての動きなどが未知ではありますので、今一度、しっかりDBに関して自分で把握しつつ、質問させてください!
guest

0

察するにデイサービスかなにかの運行管理に用いるアプリ開発かと思いますが、どのようなUI/UX、機能にするかの全貌が見えず、また「分かりやすい」というのも割と主観的になってしまうので、的確にお答えできるかはちょっとアレですが、まぁ、参考にでもしていただければと思います。

割と簡単に考えるとして、私であれば、DBにテーブルを5つ作ります。

  1. 管理テーブル(ID、予定日(date)、車(int)、人1(int)、人2(int)、人3(int)、一言コメント(varchar))
  2. 車テーブル
  3. スタッフテーブル
  4. 訪問先テーブル
  5. 時刻と訪問先テーブル(ID、管理テーブルID、時刻(time)、訪問先(int))
  • 2〜4は、それぞれCRUD機能を作ります。
  • 1の登録formで、日付(datepicker)、車select(2から呼び出し)、人1〜3select(3から呼び出し)、時刻と訪問先を追加(配列input、Ajaxで追加できるように)とします。
  • ORマッピング的に、1 has many 5 と扱います。

というような内容が、「わかりやすい」かどうかは判断をお任せするしかありません。
正直、(時間的制限なども含め)作る人が出来る範囲というものがありますので、ご自身が分かる範囲で作ってみて、不都合が出たら改善して、という試行錯誤をしていくのが良いのでは無いかと思います。(つまりそのままでも「全然良い」とも言えると思います。)

なおDBの設計は、最も大事でそのシステムの基本と発展性を決定するもので、なんなら一番時間をかけてもおかしくはないかなと思います。

あとは、(話がちょっとズレますが)訪問先をDBに保管するのであれば、個人情報がありますので、セキュリティはしっかりされた方がよいかなと思います。

投稿2016/03/15 10:40

amaranthine

総合スコア501

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

Z-TALBO

2016/03/16 08:52

ありがとうございます。 今まで、簡単なPHPの練習などでしかDBを扱っていなかったので、改めて勉強しなおそうと思っています。 まだ、全体的な動き(検索の仕方は?予定の入れ方?)などをしっかり見極めて、今一度DBに関して疑問が出たら質問いたします。 本当にありがとうございました!
guest

0

(バージョンに依存してしまうのですが、)MYSQL5.7からJSON型というデータ型が使えます。
こちらを使えば、MYSQLに配列(JSON)で格納できますので、1レコードで済みます。
JSONとPHPは相性がいいので割と便利です。(DB設計とは逸脱してしまいますが・・・)
1.訪問予定日の選択
2.乗車予定の車の選択
3.乗車予定スタッフの選択(必ず三名乗車)
4.訪問予定先の登録(最小1名~最大10名)
5.訪問予定時刻の登録(4同様)
6.一言コメント用

例えば

DDL

1CREATE TABLE `ListTable` ( 2 `id` int(10) NOT NULL AUTO_INCREMENT, -- キー 3 `date` date NOT NULL , -- 訪問予定日 4 `car` varchar(50) NOT NULL , -- 車 5 `datas` json NOT NULL , -- 下記$datasをJSONにして格納 6 `comment` text NOT NULL , -- コメント 7 PRIMARY KEY (`id`) 8)

PHP

1$datas = array( 2 'staff_name' => array('a', 'b', 'c'), //スタッフ配列 3 'visit_place' => array('AAA', 'BBB', 'CCC', 'DDD',), //予定先 4 'visit_time' => array('10:00', '11:00', '12:00', '14:00',), //予定時刻 5); 6//配列→JSON 7json_encode($datas); 8//JSON→配列 9json_decode($datas);

という感じです。
スタッフで絞り込みしたいとかがあればJSON部分にインデックスも作れますが、データリカバリーがちょいと面倒そうです。
以上、参考になれば!!

投稿2016/03/16 01:38

編集2016/03/16 01:41
roast_chicken

総合スコア254

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

Z-TALBO

2016/03/16 09:01

JSONというのは、見たことや聞いたことがありますが、触ったことがなく、違う面での回答大変ありがとうございます! テーブルの設計の見直しなどをやりつつ、この辺りも参考にさせていただきます!
guest

0

混乱のもとかもしれませんが、一つの考え方として…
あ、その前に、別なテーマの質問は、別に起こした方がよいかもしれません。
後で見返す場合や、他の方が見に来たときに、これってどの話?とならないために...

まず、「訪問予定」が主目的となっていますので、訪問予定単位にIDを振って管理すると考えます。
すると、訪問予定を管理するテーブルがまず必要になるでしょう。
・訪問予定管理テーブル=訪問予定ID、訪問日、配車管理ID、スタッフ管理ID、訪問先管理ID、コメント
可変の項目があるので、それらは別なテーブルで管理したほうが良さそう。
・配車管理テーブル=配車管理ID、訪問予定ID、車ID(、利用日)
・スタッフ管理テーブル=スタッフ管理ID、訪問予定ID、スタッフID、訪問日時
・訪問先管理テーブル=予定先管理ID、訪問予定ID、訪問先ID、訪問日時
IDを具体的なデータと紐付けるテーブルを用意。
・車データテーブル=車ID、メーカー、車種(というか車名?)、その他必要なデータ
・スタッフデータテーブル=スタッフID、名前、役職とか・・・
・訪問先データテーブル=訪問先ID、訪問先名、場所とか・・・

さっと考えただけなので、抜け等あるかもしれませんが、テーブルの関連図を作るとわかりやすいと思います。

参考までに...

投稿2016/03/18 05:43

schi_heil

総合スコア78

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

Z-TALBO

2016/03/18 08:47

回答ありがとうございます! やはり、ここまでの量になると、逆に見づらいし、何が質問かわからなくなりますね。 そして、アドバイスもありがとうございます! 参考にさせていただきます!
guest

0

訪問予定を登録するテーブルということですが、なぜ訪問 予定日単位 になっているのか解りづらいですね。
シンプルに考えるなら、4番の「訪問予定先の登録(最小1名~最大10名)」これの1名分(1訪問先)が1レコードとなるように設計した方が楽そうなのにな、と考えてしまいます。
訪問先毎に予定時刻がありますし、コメントも登録したいだろうし、訪問先に同行するスタッフも違うだろうという予想です。

ただ、もしかしたら営業やデイサービス等のお仕事で、訪問予定を管理したいのではなく社用車の占有予定を管理したいのかな?
と、考えました。つまり、
・一日その車に乗るスタッフは途中で変更されない
・その車で訪問する先を管理したい
・その車に訪問先を追加する際に、時間の被りが無いようにしたい
・その車の空き時間を簡単に把握したい
となると、社用車単位で設計した方が解りやすいと思います。

いずれにしろ、もう少し背景情報が欲しいですね。
でないと、テーブルに登録する際にどういうValidationチェックを施すべきなのか、それによってどういう設計がいいのかも変わってしまいますので。

投稿2016/03/16 02:04

退会済みユーザー

退会済みユーザー

総合スコア0

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

Z-TALBO

2016/03/16 09:04

回答ありがとうございます! 確かに、予定日単位になっている部分を訪問先での1レコードとして考えるともっとシンプルですね。 おっしゃる通り、介護関係の仕事での感じで作成してみようと思っています。 どの単位で考えるか?少し自分の中で設計を立て直して、またご意見いただきたいなと思っております!
guest

0

ベストアンサー

システムが完成してから、テーブル設計を変更するのは、システムを作りなおすのに近い労力が
かかります。そのため、プログラミムで対応することが多いですが、そうなってしまうと今度はプログラム
が複雑になり、データも複雑になり追加要件に対応できなくなっていきます。

ちょっとくどい感じになりますが、具体的に問題点について考えてみます。

今回質問があった内容で考えると下記の様な要件が後で追加されそうです。

  1. 誰それのある日の予定を確認したい
  2. 例外的に乗車スタッフが1人や2人の場合がある
  3. 例外的に一つの訪問先に2台の車が必要
  4. 予約の際に、車が空いているか検索して、空いている車のみを予約出来るようにする。
  5. 例外的に乗車スタッフが3人を超える場合がある

1の場合、ride_staff_A・ride_staff_B・ride_staff_Cでの検索結果を結合して
表示する必要があり、複雑になってしまします。スタッフ予定テーブルがあり、訪問予定テーブルの
予約IDを持っていたら、検索し易いと思いませんか?

2の場合、ride_staff_B・ride_staff_Cがnull許容か、ダミーのスタッフがあれば問題ありませんので、
テーブル設計上の問題はありません。

3の場合、訪問予定テーブルにride_car_Bという項目を追加すれば問題なさそうですが、4のように
車の予定を検索したいという追加要件が出た場合に問題になります。車予約テーブルがあれば問題が
なくなります。

5の場合、2の時と逆で項目の追加が必要になります。1の要件の対応でide_staff_A・ride_staff_B・
ride_staff_Cの結合を行って対応した場合、検索の対象にride_staff_Dを追加しなければならなくな
ります。スタッフ予定テーブルがあれば、登録画面での人数制限を緩和するだけですみます。

ここまでの例で示したかったのは、繰り返しの項目は変更に弱く問題になる可能性が大きいということです。

対応としては、繰り返し項目を別テーブルにすることで、登録件数の制限をなくすという方法が有効です。
これを第一正規化と呼び、DBが設計の基本として知られています。

したがって、訪問予定先に関しても別テーブルが望ましいです。
(特定の訪問先の訪問履歴がほしいという要件に対応出来るようになります。)

大抵の場合は、先読みはせず最小範囲でシステムを構築するのがセオリーですが、DB設計に関し
ては正規化(できれば第三正規化まで)がよく推奨去れています。実際には、全部の要件が追加され
るわけではありませんが、1つ2つ追加要件があっただけで十分元がとれるので私もおすすめします。

結論としては、(ちょっと多いと感じるかもしれませんが)下記の様なテーブルを設計を提案します。

  1. 訪問ルート(ルートID・日付・コメント)
  2. 訪問先予定(ルートID・訪問先予定ID・日付・予定時刻・コレント)
  3. 車予定(ルートID・車ID・日付(冗長だが・・・))
  4. 乗車予定(ルートID・車ID(必要であれば)・スタッフID)

追加で、車・スタッフ・訪問先のテーブルも必要になってくるかもしれませんが、これらは必要に
なってからの追加でも問題無いとおもいます。

投稿2016/03/15 12:43

iwamoto_takaaki

総合スコア2883

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

Z-TALBO

2016/03/16 09:00

しっかりと回答いただきありがとうございます! 実は第一正規化などの言葉に関してほとんど未知でした。。。 PHPというのをやっていく中で、とりあえずDBもつついてみたくらいのレベルでしたので、、、 回答いただいた内容を参考にテーブルの作成を少しやってみたいと思います。 また、わからない点がどんどん出てきてしまうと思いますので、またご意見お願いいたします。
iwamoto_takaaki

2016/03/16 14:26

正規化は学んでいないと失敗していても、それに気づかないので、学ぶことをおすすめします。また質問してください。
ikuwow

2016/03/22 00:53

正規化を学ぶべきであることには同意です。DB設計の本を入手すれば正規化についての説明は多く出てくると思います。DB設計であとのコードの書き方も楽になったり辛くなったりするので、よく考えてみるとよいと思います。
guest

0

自分であれば、1,2,3,6は基本的に固定であることが決まっているのでそのままで4,5は別テーブルに分けますね。

訪問予定先の会社?情報は別テーブルで持っておいて、idを入れるだけにしますね。

schedule_visitsテーブル
id
schedule_id ←訪問情報のidです(質問内容でいうtestテーブルのid
company_id?←これは会社だったらですが、訪問予定先情報のidを入れます
visit_time

こんな感じでしょうかね・・・
私の場合だと、訪問スケジュール情報、訪問スケジュールの訪問予定先、訪問予定先情報の、3つのテーブルで分けると思います。
しかし、3が可変になる可能性があるとか、コメントが複数になるとかなってくると話は別になってきますね。

あくまでも参考程度で。

投稿2016/03/15 10:41

編集2016/03/15 10:49
fagai

総合スコア2158

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

Z-TALBO

2016/03/16 08:56

DBの設計に関して、もっと勉強していこうと思います。 テーブルに関しても、複数のテーブルでどうこうするというのがやったことありませんので、少し自分で見てみて、またご意見お願いできますでしょうか?
guest

0

ぜひ、ER図をかいてみてください。
それを投稿すれば、いろいろな指摘、構築案が上がってくると思います。

投稿2016/03/19 00:56

katoy

総合スコア22324

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

Z-TALBO

2016/03/19 03:39

回答ありがとうございます! これだけの回答をいただいて、ER図というのもはっきり言うとわかっていなかったのですが、今それを書いてみている途中です! 参考サイトのご提示ありがとうございます!
guest

0

データベースはあくまでもデータの蓄積がメインですので、結果表示はプログラムに任せるべきかと思います。
ただ、一つのテーブルに入れる必要はなく、適度に正規化してテーブルを分けることも必要かとは思います。

投稿2016/03/15 10:29

T.Yokotani

総合スコア141

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

Z-TALBO

2016/03/16 08:49

実は、DBに関してはPHPのついでに少し勉強している程度でした、、、 正規化という言葉もはっきり言って知りませんでしたが、今回改めて勉強してみようと始めてみます! ありがとうございました!
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

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

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問