我最近被问到一个假设的基于网络的预订系统的面试问题,以及我如何设计数据库模式以最大限度地减少重复并最大限度地提高灵活性.
用例是管理员将属性的可用性输入系统.可能有多个时间段设置.例如,2009年4月1日至2009年4月14日和2009年7月3日至2009年7月21日.
然后,用户仅能够在相同或更短时段可用的时段中进行预订.
您如何将这些信息存储在数据库中?
你会使用简单(真正简化)的东西吗?
AVAILABILITY(property_id, start_date, end_date); BOOKING(property_id, start_date, end_date);
然后,您可以轻松地构建一个网页,其中显示可用日历,其中已预订的期间已被清空.从这个数据库模式构建报告会很容易吗?它看起来如此简单吗?
对于可用性和预订,使用单个表可能更容易,粒度为1天:
property_date (property_id, date, status);
列状态将具有(至少)以下2个值:
可得到
预订
输入一段可用时间,例如4月1日到14日,需要(应用程序)在property_date中插入14行,每行的状态为"Available".(对用户来说,它看起来应该是一个单一的动作).
在4月3日至11日期间预订酒店需要检查每天是否存在"可用"行,并将状态更改为"已预订".
这个模型可能看起来有点"冗长",但它有一些优点:
检查任何日期的可用性很容易
添加预订会自动更新可用性,没有单独的可用性表可以保持同步.
在网页中显示可用性非常简单
很容易添加新的状态来记录不同类型的不可用性 - 例如关闭以进行维护.
NB如果"可用"是一个属性的最常见的状态时,它可能是更好的反向逻辑,以便有一个"不可用"状态,以及一个日期不存在的行的意味着它是可用的.