日中の部屋の予約可能時間などの情報を保存するシステムを更新 (書き換え) することを検討しています。現在、部屋が空いている開始時刻と日付を 1 つのテーブルに保存し、別のテーブルに個別の予約時間を保存しています。
表面的には、このように情報を保存することは論理的なアイデアのように思えましたが、時間が経ち、システムに大きな負荷がかかるようになると、このデータ構造は非効率的であることに気付き始めました。（すべての部屋を検索して空室時間を計算するのは集中的な操作になります。部屋が特定の時間空室である場合、要求された時間に対応するのに十分な時間空室がある時間です）。
私たちは、システムをより効率的にする方法についてぐるぐる回っており、これにアプローチするためのより良い方法が必要であると感じています. これについての提案や、このようなものを構築する方法について調べる場所はありますか?
この本は刺激的であり、時間管理/制約を含むあらゆる種類のデータベースにとって必読であることがわかりました。
(編集者による追加: この本は、 Richard Snodgrassのホームページからオンラインで入手できます。良い本です。)
@Radu094 さんが良い情報源を教えてくれましたが、それを処理するのは大変です。
恐ろしく実用的なレベルで、予定と利用可能な情報を 2 つのテーブルではなく 1 つのテーブルに記録することを検討しましたか? 毎日、時間を「まったく利用できない」（オフィスが開く前、オフィスが閉まった後、そのようなことが起こった場合）、「利用できる - 割り当て可能」、「利用できない」に分割します。これらの (2 つまたは) 3 つのクラスの予約は、連続した間隔で記録されます (各間隔の開始時刻と終了時刻が 1 つのレコードに記録されます)。
部屋ごと、日付ごとに、「使用されていない」予約のセットを作成する必要があります (「使用不可」にするかどうかによって、セットは 1 つの「使用可能」レコードになる場合もあれば、早番や早番が含まれる場合もあります)。遅いシフトの「決して利用できない」記録も）。
次に、どのような質問をしているのかを理解する必要があります。例えば：
これは可能性のごく一部にすぎません。しかし、細心の注意を払うことで、クエリは扱いやすくなります。DBMS での制約の検証は難しくなります。つまり、時間 [T1..T2) が予約された場合、他の誰も [T1+00:01..T2-00:01) または他の重複期間を予約しないようにします。ウィキペディアや他の場所 ( uci.eduのこれを含む) でAllen's Interval Algebraを参照してください。