預訂應用程序的數據庫設計，例如酒店

Question

我已經建立了一個，但我確信它是錯誤的。

我有一張用於客戶詳細信息的表格，還有一張包含每個入住日期的表格（即一周的假期將有七條記錄）。

有沒有更好的辦法？

我用 MySQL 在 PHP 中編碼

Answer 1

給你 go

我在這個頁面上找到了它： 免費數據庫模型列表。

警告：目前（2011 年 11 月），Google 報告該網站包含惡意軟件： http://safebrowsing.clients.google.com/safebrowsing/diagnostic?client=Firefox&hl=en-US&site=http://www.databaseanswers。 org/data_models/hotels/hotel_reservations_popkin.htm

Answer 2

我在旅游業工作，曾參與過許多不同的 PMS。 我設計的最后一個方法是每晚每位客人排一排，這是我遇到的最好的方法。 在行業中，每晚住宿都有特定的信息。 例如，您需要在預訂時知道每晚住宿的價格。 客人也可以在入住期間移動房間。

在性能方面，執行等於查找比 MySQL 中的范圍更快，因此 startdate/enddate 方法會更慢。 要查找一系列日期，請執行“日期在（日期）中的位置”。

我使用的架構大致是：

Bookings (id, main-guest-id, arrivaltime, departime,...)

BookingGuests (id, guest-id)

BookingGuestNights (date, room, rate)

Answer 3

你需要問自己一些問題：

• 您是否有理由需要記錄入住的每一天？
• 你能不能只為住宿准備一張桌子，並有一個到達日期和入住天數或出發日期？
• 是否有與一位客戶的住宿相關的特定數據位每天都不同？

Answer 4

有些事情可能會破壞您的 model。 這些可能不是問題，但您應該咨詢您的客戶，看看它們是否可能發生。

• 少於 1 天的住宿（例如，在一些商務酒店中，短暫的中午住宿很常見）
• 延遲退房/提前入住。 如果您只是測量夜晚，而不是日期/時間，您可能會發現很難安排這些，或者看到潛在的沖突。 我們的一位客戶想要四個小時的間隔，而不是總是上午 10 點到下午 2 點。

Answer 5

哇，謝謝大家的回答。

我對架構進行了長時間的思考，並在嘗試另一種方式並且難以轉換為 html 之后采用了記錄 = 夜間方法。

我使用 CodeIgniter 和內置日歷 Class 來顯示預訂信息。 通過這種方式檢查是否有可用的日期更容易（至少在嘗試之后），所以我選擇了它。 但我確信這不是最好的方法，這就是我問這個問題的原因。

也感謝數據庫答案鏈接。

最好的，

梅

Answer 6

那有什么問題？ 記錄客戶停留的每個日期允許我認為是相當標准的報告，例如能夠顯示任何給定日期的預訂房間數量。

Answer 7

答案在很大程度上取決於您的要求......但我希望只需要存儲他們逗留的開始和停止日期的記錄。 如果您更多地解釋您的問題，我們可以為您提供更多詳細信息。

Answer 8

我認為，每天一個元組有點矯枉過正。 “停留”表上的幾列就足夠了。

stay.check_in_time_scheduled
stay.check_in_time_actual
stay.check_out_time_scheduled
stay.check_out_time_actual

Answer 9

是否需要為一個人停留的每一天創建記錄？ 只有當每一天都很重要時才需要，否則有一個 Customer/Guest 表來包含客戶詳細信息，一個 Booking 表來包含客人的預訂。 預訂表將包含房間、開始日期、結束日期、客人（或客人）等。

如果您需要記錄其他內容，例如支付的活動或膳食，請根據需要將這些內容添加到其他表格中。

Answer 10

減少每次停留的條目數量的一種可能方法是存儲時間范圍，例如開始日期和結束日期。 我需要知道您針對數據運行的操作以提供更具體的建議。

一般來說，如果您需要檢查有多少客戶在給定日期停留，您可以使用存儲過程來執行此操作。

對於某些特定操作，您的設計可能很好。 即使是這種情況，我仍然會持有一個“訪問”表，將客戶與獨特的住宿聯系起來，以及一個“訪問天數”表，我將在其中解決每個客戶的停留時間。

阿薩夫。

Answer 11

您正在用查詢簡單性（可能還有性能）來權衡數據庫大小

您當前的 model 提供了簡單的查詢，因為它很容易查詢客人數量，晚上 n 房間 X 的空缺等等，但數據庫大小會迅速增加。

移動到開始/停止或開始/數晚 model 會產生一些......有時有趣的查詢:)

所以很多選擇與你的 SQL 技能水平有關:)

Answer 12

我不關心圖中的模式。 比較難看。

架構摘要

表：訪問

訪問表包含在酒店住宿的每一晚的一行。

注：訪問包含

• ix訪問
• ix客戶
• dt
• s注

表：客戶

• ix客戶
• 名字
• s姓

表：留下

停留表包括描述整個訪問的一行。 每次更新訪問時都會更新。

• ixStay
• dt到達
• dt離開
• s注

筆記

一個 web 應用程序是兩件事：SELECT 動作和 CRUD 動作。 大多數 web 應用程序是 99% SELECT 和 1% CRUD。 與 SELECT 相比，規范化對 CRUD 的幫助更大。 您可能會看到我的架構並感到恐慌，但它很快。 您將不得不為任何 CRUD 活動做少量額外的工作，但您的 SELECTS 會快得多，因為您的所有 SELECTS 都可以命中 Stay 表。

我喜歡 Jeff Atwood 的說法：“規范化直到它受傷，反規范化直到它起作用”

對於忙碌的酒店經理使用的網站來說，它的運行情況與運行速度一樣重要。