選項1
你將存儲的可用性與3列(假設一個ID山坳來識別用戶)
availability_start, availability_end, user_id
搜索基於日期時間,然後會像
select
user_id
from
availability
where
desired_datetime > availability_start
and
desired_datetime < availability_end
根據您想要提供的功能,您可能需要刪除過去的日期。顯然你需要根據人們的週期日期定義來決定存儲日期。
選項2
如果它始終是作爲選擇星期和時間對這些天的各天一樣簡單。您可以將循環日期存儲爲
user_id, day_of_week, availability_time_start, availability_time_end
開始和結束時間不需要日期分量。搜索基礎上,一週中的一天和時間會是這樣的
select
user_id
from
availability
where
desired_day_of_week = day_of_week
and
desired_time > availability_time_start
and
desired_time < availability_time_end
順便說一句,有其創建這樣重複日期的模式,我工作的地方,我們使用this協助圖書館(JAVA) ,可能會有適合您的語言的RFC 2445實現。
如果你使用類似的東西,那麼你將不會被存儲實際日期,但復發的模式,不會真正幫助你解決問題的只是細節。我們通過簡單地從遞歸定義中獲取這些值並將它們保持到db一個字段到一個列來存儲這些細節。
然後,您也可以將日期/時間存儲在未來的某個確定的時間內,並對重複定義的任何更改重新計算這些值,這顯然可能會變成相當大的操作,具體取決於人們有多少個時間表以及如何遠在將來你想存儲數據。
約束絕對是一個好主意。我目前的方法使用了generate_series,但是我擔心爲了彌補記錄而效率低下,不會使用索引。 – mlomnicki 2009-09-02 11:31:24
我認爲你會沒事的。但是,爲了獲得最佳性能...您可以將視圖實現爲緩存可用性表,而不是一次更新整個事件,而是使用觸發器根據更改的規則以及如何選擇性地插入或更新。然後,您可以針對物化視圖進行查詢以獲得可用性,同時仍保持單獨的規則。 在走這條路線之前,我至少會對視圖進行一次EXPLAIN ANALYSE來衡量性能。 – 2009-09-02 12:32:54
這絕對是最好的建議。但是我沒有發現任何關於'緩存可用性表'的信息。如何在postgres中處理它?請給我一個鏈接或任何基本的指導方針。 – mlomnicki 2009-09-02 13:13:41