我們正在研究更新（改寫）我們的系統，該系統存儲有關人們何時可以在白天預訂房間等信息。現在我們將開始時間和時間以及房間的可用日期存儲在一張表中，而在另一張表中我們存儲了各個預約時間。從表面上看，以這種方式存儲信息似乎是一個合理的想法，但隨着時間的推移以及系統承受了沉重的負擔，我們開始意識到這種數據結構看起來效率不高。 （搜索所有房間的可用時間並計算房間何時可用，這變得非常繁瑣，如果房間在特定時間內可用，是可用時間足夠長以容納所需時間的時間）。時間日曆數據結構
我們已經圍繞如何使系統更高效，並且我們覺得必須有更好的方法來解決這個問題。有沒有人有關於如何去做這件事的建議，或者有任何地方可以看看如何構建這樣的東西？
我發現這本書是鼓舞人心，一個必須閱讀任何類型的數據庫，涉及時間管理/約束：
Developing Time-Oriented Database Applications in SQL
（通過編輯補充：book可在網上，通過這是一本好書。）
@ Radu094 @已經指出你是一個很好的信息來源 - 但它會很難處理。
在可怕的務實水平上，你有沒有考慮在一張表中記錄約會和可用信息，而不是在兩張表中？對於每一天，將時間分成「從不可用」（辦公室開放之前，辦公室關閉之後 - 如果發生這種情況），'可用 - 可以分配'和'不可用'。這些（兩個或三個）預訂類別將以連續的間隔記錄（在單個記錄中的每個間隔的開始和結束時間）。
對於每個房間和每個日期，有必要創建一組「未使用」預訂（取決於您是否選擇「不可用」，該集合可能是一個「可用」記錄，或者可能包含早班和晚班「無法提供」的記錄）。
然後你必須弄清楚你問的是什麼問題。例如：
這只是可能性的一小部分。但是對細節的關注和關注，查詢變得易於管理。驗證DBMS中的約束將會更困難。也就是說，確保如果時間[T1..T2]被預訂，則其他人無法預訂[T1 + 00：01..T2-00：01）或任何其他重疊時段。請參閱維基百科和其他地方的Allen's Interval Algebra（包括此處的uci.edu）。