私は実際にホテル予約システムの設計と実装に取り組んできましたが、私の経験に基づいて次のアドバイスを提供できます。
日付とホテルの個々の組み合わせごとに1つのレコードを保存する、2番目の設計オプションをお勧めします。その理由は、ホテルの料金が複数の日にわたって同じである期間がありますが、それはより可能性が高いからです。 それは、空室状況に応じて、時間の経過とともに変化し、異なるものになります（ホテルは、空室状況が低下するにつれて宿泊料金を引き上げる傾向があります）。
また、特定の日に固有の、保存する必要のある他の重要な情報があります。
- ホテルの空き状況を管理する必要があります。つまり、日付 x yがあります 利用可能な部屋。これはほぼ確実に日によって異なります。
- 一部のホテルには、ホテルが短期間（通常は特定の日）利用できない停電期間があります。
- リードタイム-一部のホテルでは、特定の日数だけ前に部屋を予約できます。これは、平日と週末で異なる場合があります。
- 最低宿泊日数。この日もxに滞在する必要があることを示す、個々の日付ごとに保存されたデータ 宿泊日数（週末など）
また、1週間の長期滞在を予約している人を考えてみてください。各日付の料金記録がある場合、その滞在の各日の料金と空き状況を返すデータベースクエリははるかに簡潔です。客室料金の日付が到着日と出発日の間にあるクエリを実行するだけで、滞在日ごとに1つのレコードを含むデータセットを返すことができます。
このアプローチを使用すると、より多くのレコードを格納できますが、適切にインデックス付けされたテーブルを使用すると、パフォーマンスが向上し、データの管理がはるかに簡単になります。あなたのコメントから判断すると、あなたはかなり少量の18000レコードの領域でしか話していません（私が取り組んだシステムには数百万があり、正常に動作します）。
しない場合の追加のデータ管理を説明するため 1日に1つのレコードを保存し、ホテルの料金が100米ドルで、12月全体で20の部屋が利用可能であると想像してください。
1つのレコードから始めます：
1-Dec to 31st Dec Rate 100 Availability 20
次に、12月10日に1つの部屋を販売します。
ビジネスロジックでは、上記のレコードから3つのレコードを作成する必要があります。
1-Dec to 9th Dec Rate 100 Availability 20
10-Dec to 10th Dec Rate 100 Availability 19
11-Dec to 31st Dec Rate 100 Availability 20
その後、レートは12月3日と25日に110に変更されます
ビジネスロジックでデータを再度分割する必要があります：
1-Dec to 2-Dec Rate 100 Availability 20
3-Dec to 3-Dec Rate 110 Availability 20
4-Dec to 9-Dec Rate 100 Availability 20
10-Dec to 10-Dec Rate 100 Availability 19
11-Dec to 24-Dec Rate 100 Availability 20
25-Dec to 25-Dec Rate 110 Availability 20
26-Dec to 31-Dec Rate 100 Availability 20
これは、日付ごとに1つのレコードを保存するよりも、ビジネスロジックとオーバーヘッドが大きくなります。
いずれにせよ、システムが終了するまでに、日付ごとに1行になることを保証できます。そのため、最初からそのように設計して、より簡単なデータ管理とより迅速なデータベースクエリのメリットを享受することをお勧めします。
>