5

我们正在考虑更新（重写）我们的系统，该系统存储有关人们在白天何时可以预订房间等信息。现在，我们将房间可用的开始时间和日期存储在一个表中，而在另一个表中存储个人约会时间。

从表面上看，以这种方式存储信息似乎是一个合乎逻辑的想法，但随着时间的推移和系统负载过重，我们开始意识到这种数据结构似乎效率低下。（搜索所有房间的可用时间并计算房间何时可用成为一项密集操作。如果房间在给定时间内可用，那么它可用的时间是否足够长以适应所请求的时间）。

我们一直在讨论如何让系统更高效，我们认为必须有更好的方法来解决这个问题。有没有人有关于如何去做的建议，或者有任何地方可以寻找如何构建这样的东西？

4

2 回答 2

6

我发现这本书很有启发性，对于任何涉及时间管理/约束的数据库来说都是必读的：

使用 SQL 开发面向时间的数据库应用程序

（编辑补充：这本书可以通过Richard Snodgrass的主页在线获得。这是一本好书。）

于 2009-01-03T13:58:35.897 回答
5

@Radu094 为您指出了一个很好的信息来源 - 但处理它会很困难。

在一个非常实用的层面上，您是否考虑过将约会和可用信息记录在一个表中，而不是两个表中？对于每一天，将时间划分为“从不可用”（办公室开放之前、办公室关闭之后——如果发生这种情况）、“可用——可以分配”和“不可用”。这（两个或）三类预订将以连续的间隔记录（每个间隔的开始和结束时间都在单个记录中）。

对于每个房间和每个日期，有必要创建一组“未使用”预订（取决于您是否选择“从不可用”，该组可能是一个“可用”记录，也可能包括早班和晚班“永远不可用”记录）。

然后你必须弄清楚你在问什么问题。例如：

  • 我可以在 T1 和 T2 之间的 Y 天预订房间 X 吗？
  • 第 Y 天 T1 和 T2 之间有空房吗？
  • 在 Y 天的什么时候房间 X 仍然可用？
  • 在 Y 天的什么时候可以提供具有视听功能和可容纳 12 人的房间？
  • 谁在 Y 天早上预订了房间 X？

这只是可能性的一小部分。但是通过对细节的关注和关注，查询变得易于管理。验证 DBMS 中的约束将更加困难。也就是说，确保如果时间 [T1..T2) 被预订，那么没有其他人预订 [T1+00:01..T2-00:01) 或任何其他重叠时段。请参阅Wikipedia 和其他地方的 Allen 的区间代数（包括uci.edu上的这个）。

于 2009-01-03T16:57:00.933 回答