訂房網站DB架構

db modern web web api

skycover 2021-12-10 01:25:11 ‧ 2942 瀏覽

一般電商的DB架構可以想見的是一張多對多的表去紀錄商品跟用戶當作訂單

那像是訂房網站因為同一時間的同一間房沒辦法被重複預定
像這種時候DB會如何規劃?
還是說只能從API做阻擋呢?

看更多先前的討論...收起先前的討論...

fillano iT邦超人 1 級 ‧ 2021-12-10 07:42:42 檢舉

假設都是過夜，這樣是按照日期來賣。可以建一個calendar表來指定日期，然後在order裡面，房間的id+calendar id是唯一的索引。實務上還會有時段，就會更複雜。

海綿寶寶 iT邦大神 1 級 ‧ 2021-12-10 08:42:09 檢舉

好問題，追蹤等解答

一級屠豬士 iT邦大師 1 級 ‧ 2021-12-10 10:03:42 檢舉

訂房,除了客人的預定時段,還要考慮房務清理所需時間.這個可能會隨著房型不同有差異.或是隨著服務等級要求而有所變化. 初步可以較為單純.

copemoe iT邦好手 3 級 ‧ 2021-12-10 10:38:25 檢舉

追蹤等解答

天黑 iT邦研究生 5 級 ‧ 2021-12-10 11:09:58 檢舉

我覺得實際進DB寫入時增加檢核確認房間是不是空的以及rollback機制，再加上程式使用Queue處理應該可以降低不少風險，但是完全跟DB結構無關所以我打在這

居然解出來了 iT邦好手 1 級 ‧ 2021-12-10 12:32:11 檢舉

可以參考以下資源:
https://dba.stackexchange.com/a/125248
https://vertabelo.com/blog/designing-a-data-model-for-a-hotel-room-booking-system/

窮嘶發發發 iT邦高手 1 級 ‧ 2021-12-10 15:25:23 檢舉

日租很好處理，有預定的入住時間就直接鎖死
時租可以用時段切割，入住時間 + 時數 + 維護時間
這些都只是時間判斷，主要是判斷條件要寫好，沒那麼複雜

直播研討會

{{ item.channelVendor }} {{ item.webinarstarted }} |

直播中

㊣浩瀚星空㊣

iT邦大神 1 級 ‧ 2021-12-10 13:22:02

我會先規劃基本表如下

客戶
訂單
房間主表
房間時間表

訂單:記錄房型(房間主表ID)及使用時間。但使用時間只是單純的為了訂單顯示用。並不是主要判斷時間。
在下單時。會將「房間時間表」記錄對應房間ID startTime及endTime 。
下單會去拉房間時間表來檢查是否可以下單，及是否有重覆到時間。

skycover iT邦新手 4 級 ‧ 2021-12-10 16:13:21 檢舉

想請問為什麼要另外建一張表來查詢房間時間
而不是在訂單查詢

㊣浩瀚星空㊣ iT邦大神 1 級 ‧ 2021-12-10 17:46:58 檢舉

房間時間表記錄可刪。訂單不能刪。
訂單需要保留去年的記錄。而房間時間表只要保留今天之後的記錄就行。或是自定義要保留前幾日或幾月。
反正它只是用來當比對用。並不是實際必要的記錄值。
實際必要的記錄值在訂單上就行

這在查尋及比對上會快很多。
你不需要從訂單海來判斷時間。
畢竟這是每次訂房必要的查尋。

當然，雖然這樣說。只要訂單時間有變動。就最好做連動判斷處理。這點是需要注意的。

justtaco0121

iT邦新手 4 級 ‧ 2021-12-13 17:51:53

印象中在建立關聯性資料庫的時候，不太建議使用多對多的方式。
詳細可以看一下資料庫正規化。

感覺上預防寫入重複預定的做法會比較好，意思是使用者沒有辦法去寫入有重複時間的訂單，這樣會比送出訂單後才比對資料庫有無重複資料來得方便一點。

那在架構的方面有很多種方式來做，看哪種比較符合你想要的方式

房間有各自的行程表：訂單會在房間的行程表上做紀錄，使用者在搜尋時只會看到剩下可以預定的日期，所以新的訂單也只能寫入空的時間。類似前面星空大大的方式。
鎖定房間使用：房間可以用個 0 或 1 表示是否可以使用，這可能比較適合網咖或是 motel 那樣有櫃台人員的，有人進去表示房間不能使用，改為 0 ，有人出來清潔好表示房間可以使用，改為 1 ，因為是當下狀況，所以建議手動更改。
限制訂單：一個房間同時只會有一筆訂單，不過這樣比較像租屋網站，但也不會有重複寫入的問題。

這邊只是講一下可能的做法，詳細的執行方式跟架構還是需要完整的需求跟詳細的規劃。