Q&A
検索するキーワードは「正規化」で、第3正規形までを行うのが一般的です。
https://it-biz.online/it-skills/normalization/
前提
Ruby on Railsで「同じ時間帯に重複することを禁止した予約システム」なシステムを作っています。
今はDB設計のところで、上の要求を満たすためにはどのような設計にすればいいか悩んでおります。
実現したいこと
- 先着順で二つある貸し会議室を予約システム
- 一つの日付は午前と午後で分かれている。
- 一つの予約で同じ時間帯に二つの会議室まで予約を入れることができる。
- 一つの予約は午前or午後or終日で予約を入れることができる。
という感じです。
わかりにくいですが枠として以下のようなイメージです。
| 時間帯 | 会議室A | 会議室B |
|---|---|---|
| 午前 | ||
| 午後 |
予約例
| 時間帯 | 会議室A | 会議室B |
|---|---|---|
| 午前 | 予約1 | 予約3 |
| 午後 | 予約2 | 予約4 |
| 時間帯 | 会議室A | 会議室B |
|---|---|---|
| 午前 | 予約1 | |
| 午後 | 予約1 | 予約2 |
| 時間帯 | 会議室A | 会議室B |
|---|---|---|
| 午前 | 予約1 | 予約1 |
| 午後 | 予約2 |
| 時間帯 | 会議室A | 会議室B |
|---|---|---|
| 午前 | 予約1 | 予約1 |
| 午後 | 予約1 | 予約1 |
これを実現するためにはどのようなDB設計がいいか悩んでおります。
考えた案(問題に関係なさそうなカラムは省略)
案1
予約テーブルを作る。予約テーブルには 日付と会議室A午前,会議室B午前,会議室A午後,会議室B午後の二値をとるカラムがある。予約を行うときは、月毎に予約状況を予約テーブルから全て読み込み、動的に会議室が空いているかを判断する。
予約テーブル
| UUID | 日付 | 会議室A午前 | 会議室B午前 | 会議室A午後 | 会議室B午後 | その他予約に必要なこと... |
|---|---|---|---|---|---|---|
| hoge | 2022-11-21 | true | true | false | false | 詳細 |
| huga | 2022-11-21 | false | false | true | false | 詳細 |
その他予約に必要なことは便宜上省略していますが複数のカラムです。
メリット
DB設計が単純で明快
デメリット
バグが発生しやすい気がする(予約できるかの条件分岐が複雑になりそう)
予約状況の読み込みに時間がかかりそう。月を切り替えるだけで毎回読み込まなければいけない。
案2
予約テーブルとカレンダーテーブルを作る。予約テーブルは固有IDのみで、カレンダーテーブルには日付を主キーとするレコードがあり、カラムには日付と会議室A午前,会議室B午前,会議室A午後,会議室B午後の予約テーブルの固有IDを入れる。
予約テーブル
予約テーブル
| UUID | 日付 | その他予約に必要なこと... |
|---|---|---|
| hoge | 2022-11-21 | 詳細 |
| huga | 2022-11-21 | 詳細 |
| piyo | 2022-11-22 | 詳細 |
その他予約に必要なことは便宜上省略していますが複数のカラムです。
カレンダーテーブル
| 日付 | 会議室A午前 | 会議室B午前 | 会議室A午後 | 会議室B午後 |
|---|---|---|---|---|
| 2022-11-21 | huga | hoge | huga | false |
| 2022-11-22 | null | piyo | null | piyo |
メリット
もう既に予約が入っているかどうかの確認が明快
デメリット
そもそもカレンダーをテーブルにしていいのか？カレンダーテーブルの存在自体が不自然に思える。
レコードをもう既に数十年先まで先に入れておくのかそれとも足りなくなったら自動で追加していくように作るのか？
質問したいこと
案を二つ考えましたがどうにもピンときません。なにぶんDB設計初心者なもので本当にこれで良いのかという気持ちになります。手戻りは避けたいので慎重に設計したいです。
おそらくもっといい設計があるのではと思っています。良い考えをお持ちでしたら是非教えていただきたいです。拙い説明ですが読んでいただきありがとうございました。
その他
DB設計におすすめの本などあれば教えて欲しいです...
その場合、案2の場合、カレンダーテーブルには
日付と会議室&時間帯の二つのカラムを用意し
会議室&時間帯には{会議室A午前,会議室B午前,会議室A午後,会議室B午後}の四つの値をとるというような扱いをするのが妥当でしょうか？
考えてみましたが合っているかどうか自信がありません。。。
回答1件
0
ご提示頂いている内容だけで考えると下記のような形になるかと思います。
予約テーブル、時間テーブル*、場所テーブル*
予約テーブルのカラムは、日付、時間*、場所*、備考
（*はenumを利用すればそれぞれのテーブルを作成しなくても良いかもしれません）
実際には予約したユーザーなども登録するはずなのでもう少しテーブルが増えるかと。
投稿2022/11/22 21:58
総合スコア3365
> 同じ時間帯に重複することを禁止した予約システム
こちらはカスタムバリデーションで実現することになるはずです。
> 手戻りは避けたいので慎重に設計したいです。
慎重と言っても、回答が適切かどうかNorminさんは判断できないと思うので、ある程度のDB設計を学んだほうが良い気がします。
> DB設計におすすめの本などあれば教えて欲しいです...
書籍より、下記のような教材を利用して学ぶと短時間で一通り網羅できるかと思います。
セール中なのでお早めに…
https://www.udemy.com/course/hajimete-ronrisekkei/
あなたの回答
tips
プレビュー
