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

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两个字段就没必要了，可以干掉。
其实就按照这样的设计，用多条查询也能满足下单需求，只是很不优雅：遍历房间表，一个一个的看房间是否满足下单条件。
如果优雅一点，在内存里给每一个房间做索引，每次下单去内存里进行匹配（匹配过程也是个遍历，只是索引在内存里，而且可以直接定位房间号，效率不是那么低）。
另外：还需要一张房间类型表吧？这样你可以配置房间类型什么的。