1

私は複数のプロパティ予約システムに取り組んでおり、スキーマ設計のベスト プラクティスについて頭を悩ませています。たとえば、サイトが 5000 のプロパティをホストし、それぞれが 1 人のユーザーによって維持されているとします。各施設には予約カレンダーがあります。私の現在の実装は、1 つのテーブルが利用可能な日付用で、もう 1 つのテーブルが利用できない日付用であり、それぞれ 1 日の粒度を持つ 2 つのテーブル システムです。

property_dates_available (property_id, 日付);

property_dates_booked (property_id, 日付);

ただし、これが良い解決策であるかどうかはわかりません。別の質問では、両方の状態が表された単一のテーブル ソリューションについて読みました。しかし、それらを混同するのは良い考えなのだろうか。また、予約カレンダーは、年間 365 日すべてをデータベース テーブルに含めて 1 年間マップする必要がありますか?それとも、施設が予約可能な日のみをマップする方がよいでしょうか? 年々列数が飛躍的に増えていると思います。また、最近データベースで利用可能なプロパティを検索することを考えていますが、5000 * 365 行を調べることが、5000 * av のみと比較して悪い考えであるかどうかはわかりません。100 行。

あなたは一般的に何をお勧めしますか？この側面は無視できますか？これを実装するベストプラクティスは？

4

1 に答える 1

1

利用可能な日付のために別のテーブルが必要な理由がわかりません。予約日 (property_id, date) のテーブルがある場合は、このテーブルに簡単にクエリを実行して、特定の日付に利用可能なプロパティを見つけることができます。

select properties.property_name
from properties where not exists
(select 1 from property_dates_booked
 where properties.property_id = property_dates_booked
 and property_dates_booked.date = :date)

:date はクエリのパラメータです

実際の予約のみを property_dates_booked テーブルに入力してください (テーブルの名前を「bookings」に変更する方が簡単です)。メンテナンスのために特定の日付にプロパティが利用できない場合は、顧客が「特別」である日付の予約を入力します (「顧客」の ID が負の可能性があります)。

于 2012-12-03T10:10:38.443 に答える