我正在研究多个物业预订系统，让我对最佳实践架构设计感到头疼。假设站点托管例如5000个属性，其中每个属性由一个用户维护。每个酒店都有预订日历。我目前的实现是一个双表系统，其中一个表用于可用日期，另一个用于不可用日期，每个粒度为1天。
property_dates_available（property_id，date）;
property_dates_booked（property_id，date）;
然而，我不确定这是否是一个好的解决方案。在另一个问题中，我读到了有两个状态的单表解决方案。但我想知道混合起来是不是一个好主意。此外，如果将预订日历全年映射到数据库表格中的全年365天，或者最好只映射一个房产可用于预订的日期？我想到每年的行数急剧增加。此外，我想最近搜索数据库的可用属性，并不确定通过5000 * 365行查看可能是一个坏主意，而不是只有5000 * av。 100行。
您通常会推荐什么？这方面可以忽略吗？如何最好地实践这个？
答案 0 :(得分：1)
我不明白为什么你需要一个单独的表来查看可用日期。如果您有一个预订日期表（property_id，date），那么您可以轻松查询此表以找出给定日期可用的属性
select properties.property_name
from properties where not exists
(select 1 from property_dates_booked
where properties.property_id = property_dates_booked
and property_dates_booked.date = :date)
：date是查询的参数
只能在property_dates_booked表中输入实际预订（重命名表格和预订会更容易）。如果由于维护而在某些日期没有房产，则输入客户特殊日期的预订。 （也许＆＃39;客户＆＃39;有负面的ID）。