需要有关数据库结构的想法/建议
假设我们有 100 多家酒店，每家酒店至少有 3 种以上的房型。 我想在过去一年和未来一年保持酒店的容量。我应该如何设计数据库以最容易使用。
例子：
一家酒店有 30 间客房。 10ד标准 房”、10 x “复式房”、10 x “豪华房” 房间”我会保留这个例子 标准间。今天是：2011 年 1 月 13 日 想要保留 2010 年 1 月 13 日以来的记录 至 13.01.2012 我将存储什么 数据库有可用房间。某物 像这样（标准间）：
<块引用>2011年1月13日：10
2011年1月14日：9（表示当天已售出 1 间标准间）
2011年1月15日：8（意味着当天售出 2 个标准间）
2011年1月16日：10（当天全部可用）
2011年1月17日：7（意味着当天售出 3 个标准间）
2011年1月18日：10
等...
提前致谢。
Let's think we have 100+ hotels, and each hotel has at least more than 3 room types.
I want to hold hotel's capacity for one year in the past and one year in the future. How should i design the database for easiest use.
Example:
A hotel has 30 rooms. 10 x "Standard
room", 10 x "Duplex Room", 10 x "Delux
room" I will keep this example on
standard rooms. Today is: 13.01.2011 I
want to keep records from 13.01.2010
to 13.01.2012 What i will store in
database is available rooms. Something
like this(for standard room):13.01.2011: 10
14.01.2011: 9 (means 1 standard room sold for this day)
15.01.2011: 8 (means 2 standard rooms sold for this day)
16.01.2011: 10 (all available for this day)
17.01.2011: 7 (means 3 standard rooms sold for this day)
18.01.2011: 10
etc...
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
让我试着总结一下你的问题，看看我是否理解正确：
这建议有一个酒店表、一个房间类型查找表和一个房间表：每个房间都会有一个对其关联的酒店和房间类型的引用。
现在，由于酒店需要能够单独查看预订，因此您可能会维护一个预订表。但这些通常由房间、开始日期和住宿天数来定义，这对于您声明的报告目的来说并不理想：它不会按天细分。
因此，您可能希望维护一个“房间预订日志”表，该表仅包含每天预订的每个房间的记录：这可以像日期戳列加上房间 ID 一样简单。
这种模式可以让您通过聚合查询相对轻松地生成您所描述的输出（例如，显示每天预订的房间总数，按酒店和房间类型分组）。该模型似乎也适合 OLAP 多维数据集。
Let me try to summarize your question to see if I understand it properly:
This suggests a table of Hotels, a lookup table of Room Types, and a table of Rooms: each Room will have a reference to its associated Hotel and Room Type.
Now, since hotels need to be able to look at bookings individually, it's likely you would maintain a table of bookings. But these would typically be defined by a Room, a Start Date, and a number of Nights, which isn't ideal for your stated reporting purposes: it isn't broken down by day.
So you may wish to maintain a "Room Booking Log" table, which simply contains a record for each room booked on each day: this could be as simple as a datestamp column plus a Room ID.
This sort of schema would let you generate the output you're describing relatively easily via aggregate queries (displaying the sum of rooms booked per day, grouped by hotel and room type, for example). The model also seems like it would lend itself to an OLAP cube.
我曾经做过这样的家庭作业。基本上，您至少需要 3 张桌子：一张保存房间，一张保存预订，另一张桌子也链接在一起，因为它不是在给定时间预订的特定房间，而是特定类型的房间。
I did a homework question like this once. Basically you need at least 3 tables: one which holds the rooms, one which holds the reservations, and another table that links the too because its not a specific room that is reserved at a given time, its a specific type of room.