2015-11-30 126 views
3

現在我正在開發酒店預訂系統。酒店預訂系統價格規則數據庫設計

所以我需要在某些日期/日期範圍內存儲未來日期的價格,所以價格因不同日期/日期而異。所以我需要將這些價格&日期詳細信息存儲到數據庫。我想到了2個結構。

1模型:

room_prices : room_id : from_date : to_date : price: is_available: 第二設計: room_prices : room_id : date: price: is_available

,所以我找到了第二個方法是容易的。但隨着酒店列表的增長,所存儲的數據呈指數增長 。

假設如果我想存儲下一個(未來)一個酒店的2個月價格數據,我需要爲每個酒店創建60個記錄。

在第一個設計的情況下,我不需要那麼多的記錄。

例如:

``` 爲X酒店價格值:

1日 - 12月15日 - 10日 - 12月15 - $ 200,

1設計要求:只有1排

第二設計要求:10行 ```

我使用的MySQL,

在搜索 room_prices表時它是否有任何性能下降。

有人會建議我有更好的設計嗎?

+0

僅供參考,這不是很多行,而不是我會關心的。看看它是否是最好的方法來做到這一點(邏輯上)更重要。在這種情況下,不要考慮行數。我有一個單一日期(顯然是多個選項)的單一價格類似的系統,有超過97,000行。這個數字即使是10倍的大小也不關心我。另一個說明:單個日期的代碼邏輯更容易。 – Novocaine

+0

FWIW,我會選擇1.to_date是可選的 - 因爲它實際上就在下一個'from_date'前一天(儘管可能來自不同的年份) – Strawberry

回答

2

我認爲第一種解決方案更好,因爲您已經注意到它減少了存儲價格所需的存儲數量。另一種可能的方法是:使用單一日期並假設指定的日期有效直至找到新日期,因此基本上與第二種方法中設計的結構基本相同,但實現了內部邏輯,如果您找到指定期間的新日期。

比方說,你有房1從12月12日,從12月1日與售價$ 250價格$ 200,那麼你將有隻有兩排:

1-Dec-15 -- $200 
12-Dec-15 -- $250 

你會在你的邏輯假設價格從指定的日期直到找到新的價格爲止有效。

+0

感謝@aleroot ...如果想更新日期的價格(說第9)其中1至12之間..所以然後我需要修改那個東西..然後它變得更復雜 – kamalakar

+0

@kamalakar我不同意這種方法是艱苦的工作來維護 - 看到我的回答低於 – CSL

+0

我不認爲它是更復雜的,我認爲這是另一種邏輯,讓你節省空間... – aleroot

4

我確實在設計和實施酒店預訂系統,並且可以根據我的經驗提供以下建議。

我會推薦您的第二個設計選項,爲每個單獨的日期/酒店組合存儲一條記錄。原因在於,儘管會有多段時間酒店的價格相同,但更多可能是,這取決於可用性,它會隨時間而變化並且變得不同(酒店傾向於隨着可用性而增加房價滴)。

還有一些特定於給定的一天,將需要存儲信息等重要的部分:

  1. 您將需要管理的酒店房源,即在日期X有 被y可用房間。這幾乎肯定會有所不同。
  2. 一些酒店有停電期間,酒店短時間(通常特定的日子)不可用。
  3. 準備時間 - 有些酒店只允許客房預訂一定的天數 天數,這可以在週末和週末 週末有所不同。
  4. 最小的夜晚,再次說,如果你在這一天的到來,你必須留X住宿天數的個別日期存儲的數據(在一個週末說)

還要考慮一個人預訂一週的住宿,如果您有每個日期的定價記錄,則數據庫查詢返回該中止日期的費率和可用性將更加簡潔。您可以簡單地執行一個查詢,其中房間費率日期在抵達和離開日期之間,以返回一個數據集,並在每次停留日期記錄一條記錄。

我認識到這種方法你會存儲更多的記錄,但有索引的表格表現很好,數據的管理將會簡單得多。根據你的評論來判斷,你只能在18000條記錄中進行談話,這是一個相當小的數量(我工作的系統有幾百萬,工作正常)。

爲了說明這個額外的數據管理,如果你切勿店每天一個記錄,想象一個酒店擁有100美元,可用於整個十二月的20間客房率:

你會開始其中一個記錄:

1-Dec to 31st Dec Rate 100 Availability 20

然後你賣在12月10日

你的業務邏輯,一個房間現在已經建立從鄰三條記錄NE以上:

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-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

然後在第3和12月25日以110

你的業務邏輯現在必須再次分裂的數據的速率變化比每個日期存儲一條記錄更多的業務邏輯和更多開銷。

我可以向你保證,當你完成你的系統後,每一個日期最終都會有一行,所以你不妨從一開始就設計它,並獲得更簡單的數據管理和更快的數據庫查詢的好處。

+0

謝謝@CSL,你在暗示我的第二個設計..我也有同感,我的疑問是如果有300家酒店,我需要存儲18000條記錄(300 * 60),因爲我需要爲下一個2給定酒店的月份。搜索時是否會導致性能下降? – kamalakar

+0

我同意@CSL,維護數據變得不那麼容易......讓我現在就只用這種方法..讓我想到數據保存當我看到PERFORMANCE問題 – kamalakar

+0

@kamalakar 18,000條記錄不會導致性能問題如果你寫正確的查詢。 – Novocaine