ホテル予約サイトDB設計：予約テーブルとは別に空き状況管理のためのテーブルを持つべきか

Question

設計したいサービスについて

DB設計の勉強中の初心者です。現在勉強のためホテル予約サイトのDB設計を考えています。
Airbnbやじゃらんのようなサービスを想定しています。

サービスのフロー
ユーザーがエリア、宿泊日などの条件で検索→条件にマッチするホテルのプランが表示→選んで予約

前提

「誰が何日から何日までどの客室タイプを予約しているか？」という情報は「予約テーブル」で管理しています。
※予約は具体的な部屋単位ではなく部屋タイプ単位で管理しています。
ホテルは予約サイトとは別に当日のチェックインチェックアウト状況を管理するようなサービスを持っているはずなので、このサービスでは部屋タイプだけ決めといて実際どの部屋に割り当てられるかはそっちで何とかしてくれというスタンスです。
もしこのサービスでも部屋単位で管理すべきなら教えてください！

部屋の空き状況をチェックする際は「予約テーブルから予約済の(希望する部屋タイプの)部屋数を数え、(希望する部屋タイプの)部屋の総数からそれを引く」ことで出すことができます。
しかし、毎回空き状況確認するために予約テーブルから計算するのはパフォーマンス的に良くないのでは？と思いました。

聞きたいこと

「客室タイプ別空き状況テーブル」なるものを別で作るべきでしょうか？
これは日ごと、客室タイプごとに空き部屋数を持っているテーブルです。

それとも冗長になるため予約テーブルだけにするべきでしょうか？

Answer 1

それとも冗長になるため予約テーブルだけにするべきでしょうか？

単純なスキーマ設計の勉強であれば、原理原則に則って、導出可能なデータは持つべきではありません。

しかし、毎回空き状況確認するために予約テーブルから計算するのはパフォーマンス的に良くないのでは？と思いました。

実務であれば要件によっては必要になる場合があります。
それは非機能要件（パフォーマンスに関する要件）を定めるところから始める必要があります。

明確な理由もなく「パフォーマンス的に良くないのでは？」という程度の話でなく、例えば実際にテストデータを入れてパフォーマンス計測等を行って決める（或いは過去のデータ等から計算で導く）、という手順を踏むべき話です。

なにを目的とした「勉強」かによりますが、実務を強く意識してやるのであれば、例えば応答時間やCPU、メモリ、ディスクI/Oの負荷などを計測する、というところまでやって「冗長なデータを持つべきか」を判断する資料を作成するところまで勉強したら良いのではないでしょうか。

また、データを重複して持つのではなく、ビューを作成するという方針も考えられます。
他の回答にもあるようにRDBMSの外側にデータを持つ方法もあります。

何が最適なのかは「要件による」としか言えないので、様々な可能性を含めて、メリットやデメリットを勉強してみるのも良いんじゃないでしょうか。

ただし、そこまでいくとシステムアーキテクチャ設計とかそういうレベルになるので、「DB設計の勉強をしています」という前提なら「必要ない」という回答で終わりです。

Comments

[allia]

回答ありがとうございます！
何となくパフォーマンスとかも考慮した方が良いのではと思い込んでいたのですが明確な根拠なく冗長にするとは良くなかったとはっとさせられました。また、冗長なデータを持たせるか判断する資料を作るという点でもアドバイスありがとうございます！非常に勉強になりました！

[gentaro]

設計にしろ実装にしろ、基本は余計な事をせずシンプルにするのが第一です。複雑性が増すごとにバグを生む可能性が飛躍的に上がります。

パフォーマンスは実務上とても重要な要素ですが、根拠のないパフォーマンス優先主義はダメです。パフォーマンスチューニングというのは、計測が全てのスタートです。システム上ボトルネックになる事が明らかになって初めてチューニングを行います。データに基づかないパフォーマンスチューニングは悪です。

「なんとなく」という理由でチューニングするのは、自己満足以外の何者でもないですし、無駄な複雑さを生む原因にしかなりません。そのため、実務では絶対にやってはいけません。

Answer 2

普通に考えるなら持つべきではないでしょう。「空き室」は「すべての部屋」から「予約済みの部屋」の差分と考えれば、計算で求めることが可能です。なので、空き室データは冗長であるとも言えます。空き室テーブルのデータと予約のデータに不整合が発生したら大変ですし、その不整合を発生させないようにする仕組みを実装するのも手間です。

ただ、空き室の計算コストが高くて、かつ空き室の計算頻度が高い（空き室情報の検索が多い）と、サーバの負荷が高くなる可能性もあります。なので、あらかじめ空き室情報をテーブルに格納して、負荷を下げる方法もありと言えばありです（DBのテーブルではなくmemcacheなどに格納するのもあり）。ただ、その場合は不整合が発生しないようにする実装をするのが大変ではあります。

ということで、ケースバイケースかと思います。

Comments

[allia]

非常に分かりやすい説明ありがとうございます！
テーブル間でデータの不整合を発生させないようにするコストは盲点でした…。
基本的に冗長にならないよう設計する良いのですね。とても勉強になりました！ありがとうございます！

Answer 3

毎回空き状況確認するために予約テーブルから計算するのはパフォーマンス的に良くないのでは？と思いました。

現実的なホテル毎の管理する部屋数で考えるなら、最大で数千程度でしょうから、気にする程のコストになるとは思えません。

なので、正規化を緩める必要は無く、別テーブルを用意する必要は無いでしょう。

Comments

[allia]

確かにホテルの部屋数ならそこまで大きな数にならなさそうですね。ありがとうございます！別テーブルを持たせずに設計してみます！