2011-11-04 73 views
2

假設有三個表的酒店預訂的簡單數據庫。解耦MySQL數據與易用性

表1:預訂 此表包含入住和退房日期,以及對適用的一個或多個房間和優惠券的參考。

表2:客房 此表包含所有酒店房間的價格,每晚的價格和牀位數量。

表3:優惠券 此表保存所有優惠券的數據。

選項#1: 如果你想保留特定月份與每個預訂的總成本的概述,你必須獲取預約,每個預約房間,和優惠券(如果有的話)。

有了這些數據,您就可以計算預訂的總金額。

選項#2: 不過,也有另一種選擇,這是存儲在預留表的總成本和折扣,使其更容易獲取這些計算。缺點是您的數據變得更加依賴並且靈活性較差。我的意思是,每次更改與預訂相關的房間或優惠券時,您都必須手動更新預訂表的總費用和折扣。

在性能(選項#2)版本數據獨立性(選項#1)方面通常推薦什麼。

更新: 這是一個MySQL數據庫,目前有超過500000行(預留),但正在快速增長。我想在早期階段優化數據庫性能,以確保UX保持快速響應。

+1

首先確保選項#1中的查詢已完全優化,然後才查找進一步的優化。 –

回答

3

讓我開始回答這個故事。 (有點簡化了。)

2011-01-01我預訂了兩晚,2011-03-01和2011-03-02的房間。你不告訴我我會得到哪個房間。 (因爲你還不知道我會得到哪個房間。)你告訴我,每晚將花費40美元。我沒有優惠券。即使您在這兩個晚上已經完全保留,您也可以將我的預訂輸入您的計算機。事實上,這兩個晚上你已經有一個人在等候名單上。 (超量預訂是正常的事情,而不是一個不正常的事情。)

2011-01-15你提高每個房間的價格5美元。

2011-02-01我再次打電話確認您還有我的預訂。您確認我已預訂了兩晚,2011-03-01和2011-03-02,價格爲40美元。 (不是45美元,你目前的價格,這不是我們的交易,我們的交易是每晚40美元)

2011-02-12一個人打電話,取消他們的2011-03-01和2011-03- 02。你還沒有確定的房間,我可以登記入住。等候名單中的另一個人現在有一個房間;我仍然在等待名單上。

2011-02-15 2011年1月1日和2011年3月2日,一人致電並取消預訂。現在我有一個房間。

2011-03-01我用優惠券登記。

  • 您可以將存儲的「當前」或「默認」價格跟各個房間,或與每個類的 房間,但你需要存儲與我們我 預約商定價格。
  • 預訂不預訂房間;他們預留潛在的房間。你不知道誰會早退,誰會遲到,誰將會取消,等等。 (根據我的經驗,偶爾有一個房間會用犯罪現場錄像帶密封 ,你不知道會持續多久。)
  • 你可以有更多的預訂比房間晚。
  • 優惠券大概可能在退房之前隨時出現。

如果你想保留特定 每月每預訂的總成本的概述,你必須獲取 預訂,房間的每個預訂和優惠券(如果有一個 存在)。

我不這麼認爲。您同意的價格應該在預訂本身。直到最後一刻才能分配特定的房間。如果每次預訂有一張優惠券,則可能需要與預訂一起存儲。

唯一的報告問題是確保您的報告清楚地報告由於超量預訂應該忽略多少預期收入。

+0

+1爲犯罪密封的房間:) – hovanessyan

+0

@Catcall:謝謝你的明確的例子。它顯示了一個簡單的例子可能相當複雜。但是,您的回答並不完全回答我最初的問題。這個例子只是這個問題的例證,也就是說,最好的做法還是建議儘可能使數據儘可能獨立。換句話說,使用最初的例子,最好是從預約中抽出成本來完成預訂,而僅僅依賴於它們與房間和優惠券的關係,或者出於性能原因,包括成本(作爲一種形式緩存機制)? –

+1

@BartJacobs:在數據庫中,頭號問題 - 性能,靈活性,獨立性 - 設計糟糕的表格。您的示例沒有太多或太少的抽象,靈活性,性能或數據獨立性。例如,預訂表只是缺少列 - 我們同意的價格。你不是「從保留中抽象出成本」;你「省略了必要的專欄」。增加商定的價格增加靈活性(使當前價格和商定價格降低),獨立性(變化的價格不影響先前的保留),*和*表現(較少的聯合)。 –

1

答案的回答取決於數據庫的大小。對於小型數據庫選項#1更好,但對於大型數據庫選項#2更好。所以如果你可以說表中有多少行,並且使用了數據庫(oracle,sqlserver等),你將得到更準確的答案。

+0

我看到這是一個宿舍,所以我認爲這是一個小基地。因此請使用乾淨的數據庫:選項#1。 – Toto