我们正在考虑更新(重写)我们的系统,该系统存储有关人们何时可以在白天预订房间等的信息.现在我们将房间的起点和时间以及日期存储在一个表格中,在另一个表格中我们存储各个预约时间.
从表面上看,以这种方式存储信息似乎是一个合乎逻辑的想法,但随着时间的推移和系统负载过重,我们开始意识到这种数据结构似乎效率低下.(搜索所有房间的可用时间并计算房间何时可用,这将成为一项密集的操作.如果房间在给定时间内可用,那么它的可用时间是否足以容纳所请求的时间).
我们已经围绕如何提高系统效率,我们认为必须有更好的方法来解决这个问题.有没有人有关于如何解决这个问题的建议,或者有任何地方可以看看如何构建这样的东西?
我发现这本书很有启发性,对于任何涉及时间管理/约束的数据库都必须阅读:
在SQL中开发面向时间的数据库应用程序
(编辑补充说:这本书可以通过Richard Snodgrass的主页在线获得.这是一本好书.)
@ Radu094已经为您指出了一个很好的信息来源 - 但是处理它会很困难.
在非常务实的层面上,您是否考虑在单个表中而不是在两个表中记录约会和可用信息?对于每一天,将时间分成"永不可用"(办公室开放前,办公室关闭后 - 如果发生这种情况),"可用 - 可以分配","不可用".这些(两个或三个)预订类将以连续的间隔记录(每个间隔的开始和结束时间在一个记录中).
对于每个房间和每个日期,有必要创建一组"未使用"预订(取决于您是否使用'永不可用',该集可能是一个'可用'记录,或者它可能包括早期轮班和迟到'永远不可用'的记录也是如此).
然后你必须弄清楚你在问什么问题.例如:
我可以在T1和T2之间的第Y天预订X会议室吗?
T1和T2之间的第Y天有空房吗?
在第Y天的什么时候X室仍然可用?
在Day Y的哪个时间是一个具有视听功能并可容纳12人的房间?
谁在第Y天早上预订了X室?
这只是可能性的一小部分.但是,通过对细节的一些关注和关注,查询变得易于管理.验证DBMS中的约束将更难.也就是说,确保如果预订时间[T1..T2],则没有其他人预订[T1 + 00:01..T2-00:01]或任何其他重叠时段.请参阅维基百科和其他地方的Allen的Interval代数(包括uci.edu上的这个).