我們認爲我們有100多家酒店，每家酒店至少有3種以上的房型。 我想在過去一年和未來一年內保持酒店的容量。我應該如何設計數據庫最簡單的使用。需要關於數據庫結構的想法/建議
實施例：
甲賓館有30間。 10×「標準 房間」，10×「複式房」，10×「Delux 房間」我會保持這個例子 標準間。今天是：13.01.2011我 想保留記錄從13.01.2010 到13.01.2012我將存儲在 數據庫是可用的房間。東西 像這樣（標準室溫）：
13.01.2011：10
2011年1月14日：9（1點指標間這一天銷售）
2011年1月15日：8（用於這一天售出2點標準間）
2011年1月16日：10（所有可用的這一天）
2011年1月17日：7（用於這一天售出300點標準間）
2011年1月18日：10
等等
在此先感謝。
讓我試着總結一下你的問題，看看我是否正確地理解它：
您有一組酒店。每個Hotel 有一組客房。每個房間都屬於 至多個可能的房間 類型之一。我們感興趣的最低級別的詳細信息 是一個房間。
這建議一張酒店表，一個房間類型查找表和一張房間表：每個房間都有一個對其關聯的酒店和房間類型的引用。
對於任何給定的一天，一個房間或者是 預訂（售）或沒有預訂（讓我們 在這一點上留下關閉部分天簡單 ）。對於 前一年和當天 當天的每一天，您想知道每個酒店有多少個 間客房可用（未預訂） 。
現在，由於酒店需要能夠單獨查看預訂，所以很可能您會保留一張預訂表。但是這些通常由房間，開始日期和夜晚定義，這對於您陳述的報告目的來說並不理想：它不會按天分解。
因此，您可能希望維護一個「房間預訂日誌」表格，該表格僅包含每天預訂的每個房間的記錄：這可能與日期戳列和房間ID一樣簡單。
這種模式可讓您通過聚合查詢（例如顯示每天預訂的房間總數，按酒店和房間類型分組）來相對容易地生成輸出。該模型似乎也適用於OLAP cube。
我做過這樣的功課一次。基本上你至少需要3張桌子：一張持有房間，一張持有預訂房間，另一張桌子連接，因爲它不是特定時間預訂的特定房間，而是特定房間類型。
這是一個非問題，或者你的理解太有限，你甚至不會問正確的問題。數據庫不是爲了最簡單的使用而設計的。它旨在有效地存儲數據並確保數據和可搜索性的完整性。訪問數據的用戶界面需要易於使用。而你的例子與數據庫結構無關。它是一個分隔字符串。 – David 2011-01-13 19:07:01
「最簡單的使用」可能是我的錯。無論如何，我將需要最好的形式來存儲它們。對不起，我沒有得到你的意思「與數據庫結構無關」和「分隔字符串」。 – Mustafa 2011-01-13 19:11:39