关于酒店订房系统的数据库设计

Question

酒店有若干房间，房间有若干类型。
给定房间数和一个时间区间（以天为单位），给定房间类型。查询数据库当前状态，如果满足订房条件则产生订单，否则返回false。如果返回false时能给出合理的订房建议则更佳。

我考虑的方案：
---------------------------------------------------------------

房间表:
room_id
room_type 房间类型
room_status 房间状态[是否空置]
room_order_id order表外键，被那个订单预定
room_order_start 时间区间左标
room_order_end 时间区间右标
...

订单表：
order_id
order_rooms 预定的房间总数
order_room_type 预定的房间类型
order_start 预定区间左标
order_end 预定区间右标
...

下订单的流程
从房间表找未预定的或者预定区间同用户选择区间不重叠的房间，如果符合条件的房间总数小于用户选择的房间数，返回false，否则返回true。

问题与疑惑
-----------------------------------------------------------------
这种设想没有整合房间资源，例如A、B房间均被预定且都在新订单选择的时间区内，都不符合查询条件。但是A、B
综合起来是满足时间区间的，A退房之后原来的B可以使用A房间。
个人感觉这个很类似内存管理的算法，用有限的房间类型和房间数来满足无限多的客人入住。本人才疏学浅，请各位
多指教。

Answer 1

拍拍脑袋想，貌似用sql查询满足不了下单流程的需求。
这个房间订单，是离散的区间集合，而下单所需要的查询是对这些离散区间取反进行查询。关系库搞不定这种查询。
针对这种离散区间的数据结构，房价表中room_order_start，room_order_end两个字段就没必要了，可以干掉。
其实就按照这样的设计，用多条查询也能满足下单需求，只是很不优雅：遍历房间表，一个一个的看房间是否满足下单条件。
如果优雅一点，在内存里给每一个房间做索引，每次下单去内存里进行匹配（匹配过程也是个遍历，只是索引在内存里，而且可以直接定位房间号，效率不是那么低）。
另外：还需要一张房间类型表吧？这样你可以配置房间类型什么的。

Answer 2

关于客房时间的判断能否这样考虑一下：

现在酒店一般是中午或者下午1、2点退房（单位为天）。按国家规定入住时间：14:00－次日12:00为一个入住周，回忆自己的亲身经历，入住的时候并没有问具体的离店时间，只是问离店日期，那么就不需要用左、右两个时间来判断期间了。

整个过程整理如下：

1. 用户入住(早于、晚于12点都有可能)，查找状态为空的客房；
2. 用户退房(早于、晚于12点都有可能，不过一般应为早于十二点)，将客房状态置空。

Answer 3

考虑一下，由于房间这个实体的数量，类型相对固定，可以将房间视作一种资源。而订单则是对资源的申请，可以通过以往的申请和资源总量算出当前可支配的资源。因此，可以通过查询历史订单检验新订单是否合法。结合房间表和房间-订单连接表，即可完整实现业务逻辑。

数据库订单表

id	        int(11)			AUTO_INCREMENT	 	 	 	 	 	 	
time_start	int(11)				 	 	 	 	 	 	
time_days	tinyint(5)
type_room       tinyint(3)				 	 	 	 	 	 	
status	        tinyint(3)

数据：

id	time_start	time_days	status
1	20110625	3	        1
2	20110626	2	        1
3	20110627	3	        1
4	20110625	1	        1
5	20110625	2	        1
6	20110624	1	        1
7	20110624	2	        1

查询所有预定20110626日类型为2的房间的订单

mysql> select * from room_orders where time_start<20110626 and (time_start+time_
days>=20110626) and type_room=2;

每日房间的预定情况是一个热查询，特别是今天、明天、后天等的预定情况，可以考虑将结果缓存。
如果有新订单提交校验，则对次查询做 count，即可算出某天被预定的2型房间总数。由于该类型的房间总数已知，减法操作即可算出某天某型房间有多少空余。一般情况，预定天数较小，依次count即可算出预定的时间区间是否有足够空房。

这个设计的缺点是查询较多，可以考虑使用文件缓存。另外，可以考虑将未来几天的空余房间信息做缓存，每次更新订单表时更新一次。