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

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

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

SQL(Structured Query Language)は、リレーショナルデータベース管理システム (RDBMS)のデータベース言語です。大きく分けて、データ定義言語(DDL)、データ操作言語(DML)、データ制御言語(DCL)の3つで構成されており、プログラム上でSQL文を生成して、RDBMSに命令を出し、RDBに必要なデータを格納できます。また、格納したデータを引き出すことも可能です。

データベース

データベースとは、データの集合体を指します。また、そのデータの集合体の共用を可能にするシステムの意味を含めます

データベース設計

データベース設計はデータベースの論理的や物理的な部分を特定する工程です。

Q&A

解決済

3回答

2948閲覧

【マスタ設計】サロン予約サイトのモデル化

退会済みユーザー

退会済みユーザー

総合スコア0

SQL

SQL(Structured Query Language)は、リレーショナルデータベース管理システム (RDBMS)のデータベース言語です。大きく分けて、データ定義言語(DDL)、データ操作言語(DML)、データ制御言語(DCL)の3つで構成されており、プログラム上でSQL文を生成して、RDBMSに命令を出し、RDBに必要なデータを格納できます。また、格納したデータを引き出すことも可能です。

データベース

データベースとは、データの集合体を指します。また、そのデータの集合体の共用を可能にするシステムの意味を含めます

データベース設計

データベース設計はデータベースの論理的や物理的な部分を特定する工程です。

1グッド

0クリップ

投稿2018/06/22 03:21

編集2018/06/22 04:24

はじめて本格的なデータベース設計をします。
周りに誰も相談出来る人がいないのでどうかご回答のほどよろしくお願いします。

前提

具体的なイメージを共有したいので、サービスはホットペッパービューティーを例にしてご質問させていただければと思います。
各サロンは独立していて、それぞれが施術メニューを持っており、それぞれが予約を受け付けることができ、それぞれがそれぞれの情報を編集できるというイメージです。

質問内容

サロンがメニュー毎に、施術可能時間(必須)、予約期限(任意)、期間限定公開(任意)を設定できるようにする場合、テーブル設計はどのようにするのがベターでしょうか?

<言葉の定義>

  • 施術可能時間(必須入力)

 いわゆる営業時間。
このメニューは夜限定とか有りうるので、あえてサロン毎ではなくメニュー毎に持っている。

  • 予約期限(任意入力)

 施術可能時間のオプションのようなもの。
この施術を受けるにはいついつまでに予約が必要といった設定。

  • 期間限定公開(任意入力)

 期間限定商品のようなもの。
ある時期限定のメニュー等、ある一定期間のみ予約を受け付けたい場合に設定。

やったこと

とりあえず以下のようなイメージで考えてみましたが、これが正しいのかも判別がつかない状況です。
もっと良いモデルの設計があるのではないかと思うのですが、今のスキル的にこれが自分の中でベストな答えです。

サロンテーブル

サロンID名前
1サロンA
2サロンB

メニューテーブル

メニューIDサロンID名前
11パーマ
21カット
32クリスマス限定カラー

時間テーブル

時間IDメニューID施術可能日施術可能時間(自)施術可能時間(至)予約期限日予約期限時間
1110:0020:0020:00
2110:0020:0020:00
3110:0020:0020:00
4110:0021:0020:00
5110:0021:0020:00
6110:0020:0020:00
7210:0020:00nullnull
8210:0020:00nullnull
9210:0020:00nullnull
10210:0021:00nullnull
11210:0021:00nullnull
12210:0020:00nullnull
1332018-12-2410:0020:002018-12-2322:00
1432018-12-2510:0020:002018-12-2322:00

※メニュー毎に365日分のレコードが出来ると恐ろしいことになるので、基本は日付単位で持つのではなく、曜日単位で持ち、アプリ側で現在日付をもとに判定するように設計してみました。
※パーマ(メニューID=1)は基本前日(月は休み)の20:00までに予約が必要ということを表しています。
※カット(メニューID=2)はいつでも予約できるということを表しています。
※クリスマス限定カラー(メニューID=3)は特定日のみ施術可能かつ、前日の22:00まで予約が必要ということを表しています。

よろしくお願いします。

m.ts10806👍を押しています

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

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

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

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

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

退会済みユーザー

退会済みユーザー

2018/06/22 03:30

施術可能日、曜日なのか、日付なのか、データ型はそこまで柔軟じゃないのではっきりさせるべきかと。
退会済みユーザー

退会済みユーザー

2018/06/22 03:35

両方です。よって文字列型を想定してます。あまりよろしくない感じはするのですがそれに変わる設計案がスキル的に思い浮かばず「期間限定公開」に対応するための苦肉の策です。方針としては質問にも記載しました「メニュー毎に365日分のレコードが出来ると恐ろしいことになるので、基本は日付単位で持つのではなく、曜日単位で持ち」です
guest

回答3

0

ベストアンサー

思い付くままにざっくりと列挙すると、

サロン(ID,名称,住所,電話番号,営業曜日時間_月~日)※住所は予約の際の地域での絞り込み想定
サロン営業時間特記(ID,サロンID,営業休業区分,開始日時,終了日時)※上記とは異なるイレギュラーを登録

メニュー(ID,サロンID,メニュー名,所要時間,料金)
コース(ID,サロンID,コース名,所要時間,限定開始日時,限定終了日時)
コースメニュー(ID,サロンID,コースID,メニューID) ※コースの構成要素。

予約(ID,サロンID,コースID,予約日時,利用者ID)
予約オプション(ID,予約ID,メニューID)

上記を元に日付を与えて展開。

追記

リンク先見ていなかったので、ちらっと見た上で再考して修正しました。
最終形というわけではなく、サロン側が操作する視点、利用者が操作する視点など、それらの視点で必要な形で取り出せるか、追加更新ができるかなどで、ブラッシュアップしていく必要はあると思います。
予約に関しても、店側のキャパシティに関する情報も必要でしょうし。
キリが無いので、こういった切り口もあるよというのが伝わっていれば良いのですが。

投稿2018/06/22 06:08

編集2018/06/22 12:18
sazi

総合スコア25138

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

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

0

サロンとメニューと時間はマスタなわけですよね。
紐づけをするテーブルを作ってみては?
ざっくりとした考え方ですが、
マスタテーブルに別のマスタテーブルのIDは持ちません。

サロンID名前
1サロンA
2サロンB
メニューID名前
1パーマ
2カット
3カラー
時間ID割愛
1ほげほげ
2げほげほ

雑過ぎですが紐づけテーブルの例

サロンメニュー時間IDサロンIDメニューID時間ID
1111
2122
3231

時間テーブルが煩雑すぎます。
非稼働日のほうが少ないのであれば、非稼働日から考えると何かいい考えが浮かぶかもしれません。
あとは、非稼働日と特殊な稼働日で分けて考えるとか。

投稿2018/06/22 05:06

szk.

総合スコア1400

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

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

0

サロンAとサロンBで同じメニューを扱うことがあるのであれば、
メニューテーブルは独立させて、時間テーブルにサロンIDを入れても良いのでは、と思いました。
メニューにサロンがあるわけではなく、サロンにメニューがあるわけですし(所属とか帰属の関係の問題)

5W1H的に考えるといいかもしれません

いつ(何時に)
どこで(どのサロンで)
なにを(どのメニューを)

投稿2018/06/22 03:29

m.ts10806

総合スコア80765

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

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

退会済みユーザー

退会済みユーザー

2018/06/22 03:40 編集

> サロンAとサロンBで同じメニューを扱うことがあるのであれば 店舗ごとに独立しているのでそれはないです。 > メニューテーブルは独立させて、時間テーブルにサロンIDを入れても良いのでは 営業時間と捉えるとそうなりますよね。実際はメニューの利用可能時間です。 夜限定のメニュー等、そのメニューを予約できる時間は最終的にメニューに紐づく想定です。
m.ts10806

2018/06/22 03:45

> 店舗ごとに独立しているのでそれはないです。 言葉が足りずに申し訳ないですが、そういう意味ではないです。 サロンとメニューを紐付けしてしまうと柔軟な対応ができないことを指摘しています。 提示の例ですと、サロンBでもカットを扱うことになったとき、サロンB用のカットの行を追加するのは汎用性に欠けませんか? 同じカットだとして価格帯が違うのであればそれも要件が抜け落ちていることになるので質問に追記していただきたく。 今の状態だと時間テーブルとメニューテーブルをわけているメリットがあまりありません。
退会済みユーザー

退会済みユーザー

2018/06/22 04:00 編集

> サロンBでもカットを扱うことになったとき、サロンB用のカットの行を追加するのは汎用性に欠けませんか? それだとサロンBがメニュー名を更新したらサロンAのメニュー名も変わりませんか? サロンAがすでに紐づけされているカットをサロンBにも紐づけさせるわけですよね > 同じカットだとして価格帯が違うのであればそれも要件が抜け落ちていることになるので質問に追記していただきたく。 すみません、価格や数量等細かい属性に関する情報についてはノイズになると思ったのであえて割愛しています。 > 今の状態だと時間テーブルとメニューテーブルをわけているメリットがあまりありません。 すみません、なぜでしょうか?
m.ts10806

2018/06/22 04:05

> それだとサロンBがメニュー名を更新したらサロンAのメニュー名も変わりませんか? サロンAがすでに紐づけされているカットをサロンBにも紐づけさせるわけですよね 質問内の要件だけではそこまで汲み取れませんでした。 あくまで「サロンがメニュー毎に~~設定する」ということで、メニュー自体は誰が持っているかというところですね。 サロン側の権限(どこまで触れるか)などもあわせて要件として追記しておいてもらえると助かります。 >> 同じカットだとして価格帯が違うのであればそれも要件が抜け落ちていることになるので質問に追記していただきたく。 > すみません、価格や数量等細かい情報についてはノイズになると思ったのであえて割愛しています。 なかったため、今起きている認識の齟齬が起きています。 提示可能な情報はなるべく全て提示すべきと思います。 特に今回のような「設計」となると1つでも項目が漏れてしまうと成り立たなくなります。 >> 今の状態だと時間テーブルとメニューテーブルをわけているメリットがあまりありません。 >すみません、なぜでしょうか? 既に述べたとおりです。 必要な要件が抜けているので、質問内容に追記してください。 ※ただ、今コメントいただいた内容だと私の回答はあまり参考にならないので追記した上で他の回答を待つことになりそうです
退会済みユーザー

退会済みユーザー

2018/06/22 04:21

説明不足すみませんでした。 ご回答ありがとうございました。 要件については補足しておきます。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

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

ただいまの回答率
85.50%

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

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

質問する

関連した質問