3

"Room"、 "Reservation"などの標準的なテーブルがあります。すべてが現在リレーショナルデータベースにあります。ホテル予約システム:予約の一泊ごとに個別の価格を保管する方法は?

「予約」テーブルには、room_id、チェックイン日、チェックアウト日などの項目が格納されます。

予約すると、システムは「RoomPrice」テーブルをチェックし、予約された各晩の費用を(日付、占有率などに応じて)取得します。費用は異なる場合があります現在の価格に応じて毎晩。
明らかに予約が行われたとき、毎晩の価格は固定されます。事実の後に部屋の価格が更新されたとしても、価格の変更前に行われたように、その予約は合意した価格にとどまります。

私の質問は次のとおりです。予約を行ったときに、毎晩これらの個別料金を合意して保存する必要がありますか?

予約の毎晩、予約ID、価格、および日付を格納する別のテーブル 'PriceForNight'を使用することを検討しています。

これが私が見る唯一の問題はスケーラビリティです。平均予約期間が5泊の場合、 'PriceForNight'テーブルは 'Reservation'テーブルより約5倍速くなります。

'PriceForNight'データは、NoSQLデータベースなどに格納する方が適切でしょうか?

もう1つのオプションとして、「予約」テーブル行の1列にカンマ区切りの文字列として各夜の価格を格納することも考えられます。たとえば、「150.00,175.00,175.00,200.00,150.00」 5泊の予約。

実際の問題は1000倍も速くなっていた場合にのみ存在するかもしれませんが、私は正しいことをしたいので、コミュニティに手を差し伸べると思っていました。

ご了承ください。

+0

とにかくこのテーブルの各夜間にエントリを作成しているので、このデータを予約テーブルに保存しないでください。 Rack RateとActual Rateの2つの列を追加できます。 –

+0

@MarkKram「予約」テーブルには、宿泊数は1つ1つしかありません。 – Alex

+0

Aaah、OK今理解しています –

答えて

3

純粋にリレーショナルなアプローチは、価格を含む予約の各夜の詳細を格納したReservationNightテーブルを持つことです。はい、テーブルは急速に成長しますが、価格をどのように保存しても、データは急速に成長します。

+0

入力いただきありがとうございます。だから私の 'PriceForNight'テーブルはあなたが提案しているものと同じですか?'reservation_id'、 'price'、 'date'? – Alex

+0

はい、私は単なる価格だけではないと思っていますが、保存されています。要は、予約ごとに1泊に保存する必要がある情報があるため、表の名前はReservationNightです。興味深い列(価格)が1つしかない場合は、テーブルの名前には入れないでください。 –

+0

全く分かりません。あなたの時間をありがとう。 – Alex

1

一般に、コンマ区切りのリストはSQLデータベースに属しません。あなたの最高の賭けがジャンクションテーブルだと言いたい。

StackOverflower Bill Karwinはここに最高のそれに答え:First Normal Formに違反することに加えIs storing a comma separated list in a database column really that bad?

を単一の列に格納された値の 繰り返しグループの、カンマで区切られた リストは、他のより実用的な問題の多くを持っているので、 :

  • 各値は右のデータ型であることを保証することはできません:、1,2,3、バナナを防止する方法はありません5
  • 外部キー制約を使用してルックアップテーブルに値をリンクすることはできません。参照整合性を強制する方法はありません。
  • は一意強制することはできません:1,2,3,3,3,5
  • を防止するための方法は、全体のリストを取得せずにリストから値を削除することはできません。
  • リスト内の特定の値を持つすべてのエンティティを検索するのは難しい。非効率なテーブルスキャンを使用する必要があります。
  • リスト内の要素を数えたり、他の集約クエリを実行するのが難しい。
  • 参照するルックアップテーブルに値を結合するのが難しい。
  • ソート順でリストを取得するのが難しい。

は、これらの問題を解決するには、アプリケーションコードのトン、RDBMS はすでに 効率的多くを提供し 改革の機能を記述する必要があります。

カンマ区切りのリストが間違っていて、私の本の最初の の章がSQL Antipatterns: Avoiding the Pitfalls of Database Programmingになりました。

非正規化を使用する必要がある場合がありますが、@OMG Poniesが言及しているように、これは例外です。任意の非関係型 "最適化"は、あるタイプのクエリに恩恵をもたらし、他の用途では のデータを犠牲にします。したがって、 を非正規化する必要があるクエリを処理する必要があるかどうかを確認してください。

+0

私は前にその答えを見たことがなかった、ありがとう。カンマ区切りのアイデアは間違いありません。 – Alex

0

固定日付の代わりに日付範囲を使用できます。

だから私は予約作る場合:

Night 27 01 2012: 20 $ 
Night 28 01 2012: 20 $ 
Night 29 01 2012: 30 $ 

デシベルでは:それは毎日が気後れ価格を持っていることは非常に一般的である場合

reservationId from  to  price 
5457848  20120127 20120128 20 
5457848  20120129 20120129 30 

は、この行の量を減少させないでしょう。しかし、verryは珍しいですが、ほとんどが1行に減ります。

+0

また、以前はこれを考慮しましたが、価格を表示する必要があるたびにデータを分解しなければならない処理オーバーヘッドが発生すると考えました。また、財務報告を作成したり分析を行ったりする場合は、夜間の分離が最も簡単な方法です。 – Alex

+0

あなたは本当に新しいテーブルですべきです。そのベストプラクティスは、より多くの行を作成します。たぶん、メインの予約にフラグを付けることができます。それは、すべての夜間にコストが同じで、その行のコストを差し引いた場合に選択するということです。そうでなければ、他のテーブルを参照してください。 – Jeff

+0

また良い提案です。私たちはそれを考慮に入れます。あなたの時間をありがとう。 – Alex

0

各夜間のコストを格納するテーブルは、1泊あたり1行が賢明です。

各部屋は1年365日以上レンタルすることができます。 (現実の世界では、それはほとんど事実です。モーテルのビジネスは実際には見た目より複雑です。)

あなたは200室を持っている場合は、年間でおよそ200 * 365行、または73000行を探しています。 (その算術は得られましたか?)その速度では、技術がまったく改善されなければ、少なくとも100年間SQL dbmsのパフォーマンスを気にする必要はありません。

this answerが役に立つ場合もあります。それは同じ考え方に従います。

+0

応答していただきありがとうございます。個別テーブルメソッドは、私たちが実装するのが一番簡単なメソッドなので、それを聞いて安心です。 – Alex

+0

@Alex:[This SO answer](http://stackoverflow.com/a/8009992/562459)は同じ考え方に従っています。 –

関連する問題