酒店预订系统的价格规则数据库设计

Question

现在我正在开发酒店预订系统。

因此我需要在未来几天的特定日期/日期范围内存储价格，因此价格会因不同的日期/日期而异。所以我需要存储这些价格＆amp;日期详细信息到db。我想到了2个结构。

第一个模型：

room_prices : room_id : from_date : to_date : price: is_available: 第二个设计： room_prices : room_id : date: price: is_available

所以我发现第二种方法很简单。但存储的数据呈指数增长 随着我的酒店名单的增长。

假设我想要为一家酒店存储下一个（未来）2个月的价格数据，我需要为每家酒店创建60条记录。

如果是第一次设计，我不需要那么多记录。

例如：

```   X酒店的价格值：

1月12日 - 15日 - 12月15日 - 200美元，

第一个设计要求：只有一行

第二个设计要求：10行 ```

我正在使用mysql，

搜索时是否有任何性能下降 room_prices表。

有人会建议我更好的设计吗？

Answer 1

我实际上致力于设计和实施酒店预订系统，并可根据我的经验提供以下建议。

我会推荐您的第二个设计选项，为每个日期/酒店组合存储一条记录。原因在于，虽然会有多个时段的酒店价格相同的时段，但更多可能，根据可用性，它会随着时间的推移而变化并变得不同（酒店往往会增加随着可用性下降的房价。）

还需要存储特定于某一天的其他重要信息：

1. 您需要管理酒店的可用性，即在日期 x 是 y 可用的房间。这几乎肯定会在一天之内发生变化。
2. 有些酒店有停电期，短时间内（通常是特定日期）酒店无法使用。
3. 交货时间 - 部分酒店仅允许客房预订 提前几天，这可能在工作日和之间有所不同 周末。
4. 最少的夜晚，再次根据个人日期存储的数据显示，如果您在这一天到达，则必须保持 x 夜晚（比如说周末）

另外考虑一个人预订一周的住宿，如果您有每个日期的定价记录，那么返回该住宿每天的费率和可用性的数据库查询会更简洁。您可以简单地进行查询，其中房价日期在抵达和离开日期之间，以返回每个住宿日期有一条记录的数据集。

我意识到使用这种方法，您将存储更多记录，但是使用索引良好的表格，性能将会很好，并且数据管理将更加简单。从你的评论来看，你只是在18000个记录的区域内谈论，这是一个非常小的数量（我工作的系统有几百万，工作正常）。

如果您不要每天存储一条记录，为了说明额外的数据管理，想象一下酒店的费率为100美元，整个12月有20个房间可用：

您将从一条记录开始：

1-Dec to 31st Dec Rate 100 Availability 20

然后你在12月10日卖掉了一个房间。

您的业务逻辑现在必须创建上述三个记录：

1-Dec to 9th Dec Rate 100 Availability 20 10-Dec to 10th Dec Rate 100 Availability 19 11-Dec to 31st Dec Rate 100 Availability 20

然后费率在12月3日和25日变为110

您的业务逻辑现在必须再次拆分数据：

1-Dec to 2-Dec Rate 100 Availability 20 3-Dec to 3-Dec Rate 110 Availability 20 4-Dec to 9-Dec Rate 100 Availability 20 10-Dec to 10-Dec Rate 100 Availability 19 11-Dec to 24-Dec Rate 100 Availability 20 25-Dec to 25-Dec Rate 110 Availability 20 26-Dec to 31-Dec Rate 100 Availability 20

与每个日期存储一条记录相比，这是更多的业务逻辑和更多的开销。

我可以向您保证，当您完成系统时，最终每个日期最终会有一行，因此您不妨从头开始设计它，并获得更轻松的数据管理和更快的数据库查询的好处。

Answer 2

我认为第一种解决方案更好，因为您已经注意到它可以减少存储价格所需的存储空间。另一种可能的方法可能是：拥有一个日期，并假设指定的日期有效，直到找到新的日期，所以基本上与您在第二种方法中设计的结构相同，但实现了一个内部逻辑，如果您在其中覆盖日期找到指定时间段的新日期。

假设从12月1日开始，房间价格为200美元，12月12日起价格为250美元，那么您只有两排：

1-Dec-15  -- $200
12-Dec-15  -- $250

您将在逻辑中假设价格从指定日期起有效，直至找到新价格。