目前我正在开发酒店预订系统。
所以我需要在未来几天的特定日期/日期范围内存储价格，因此价格会在不同的日期/日期发生变化。所以我需要将这些价格和日期详细信息存储到数据库中。我想到了 2 个结构。
第一个模型:
房间价格:
房间编号:
从日期 :
迄今为止 :
价格:
可用:
设计二:
房间价格:
房间编号:
日期:
价格:
可用
所以我发现第二种方法很简单。但存储的数据呈指数增长 随着我的酒店名单的增加。
假设如果我想为一家酒店存储下一个( future )2 个月的价格数据，我需要为每家酒店创建 60 条记录。
如果是第一种设计，我不需要那么多记录。
例如:
``` X 酒店的价格值:
2015 年 12 月 1 日 - 2015 年 12 月 10 日 -- 200 美元，
第一个设计要求:只有 1 行
第二个设计需要:10行 ```
我正在使用 mysql，
搜索时是否有任何性能下降 房间价格表。
有人会建议我更好的设计吗？
最佳答案
我实际上从事过酒店预订系统的设计和实现工作，可以根据我的经验提供以下建议。
我会推荐您的第二个设计选项，为每个单独的日期/酒店组合存储一条记录。原因在于，尽管有时酒店的房价在几天内都是相同的，但可能根据可用性，它会随着时间的推移而变化并变得不同(酒店往往会增加客房价格随着可用性下降)。
还有其他需要存储的特定于特定日期的重要信息:
- 您需要管理酒店可用性，即在日期 x y 个房间可用。这几乎可以肯定每天都会有所不同。
- 一些酒店有停电期，酒店会在短时间内(通常是特定日期)不营业。
- 提前期 - 一些酒店只允许在特定时间内预订房间 提前的天数，这在工作日和 周末。
- 最短住宿天数，同样是按个人日期存储的数据，表示如果您在这一天到达，您必须住 x 晚(比如周末)
同时考虑一个人预订了一周的住宿，如果您有每个日期的定价记录，那么返回该住宿每一天的房价和空房情况的数据库查询会更加简洁。您可以简单地执行一个查询，其中房价日期介于到达日期和离开日期之间，以返回一个数据集，其中每个住宿日期都有一条记录。
我意识到使用这种方法您将存储更多记录，但使用索引良好的表性能会很好并且数据管理会更简单。从您的评论来看，您只在 18000 条记录的范围内交谈，这是一个非常小的数量(我工作的系统有几百万条并且工作正常)。
如果您不每天存储一条记录，为了说明额外的数据管理，假设一家酒店的房价为 100 美元，整个 12 月有 20 个房间可用:
您将从一条记录开始:
12 月 1 日至 12 月 31 日房价 100 可用性 20
然后您在 12 月 10 日卖掉一个房间。
您的业务逻辑现在必须根据上面的记录创建三个记录:
12 月 1 日至 12 月 9 日房价 100 可用性 20
12 月 10 日至 12 月 10 日房价 100 可用性 19
12 月 11 日至 12 月 31 日房价 100 可用性 20
然后汇率在 12 月 3 日和 25 日变为 110
您的业务逻辑现在必须再次拆分数据:
12 月 1 日至 12 月 2 日利率 100 可用性 20
12 月 3 日至 12 月 3 日房价 110 可用性 20
12 月 4 日至 12 月 9 日房价 100 可用性 20
12 月 10 日至 12 月 10 日利率 100 可用性 19
12 月 11 日至 12 月 24 日房价 100 可用性 20
12 月 25 日至 12 月 25 日房价 110 可用性 20
12 月 26 日至 12 月 31 日房价 100 可用性 20
与每个日期存储一条记录相比，这需要更多的业务逻辑和更多的开销。
我可以向您保证，当您完成时，您的系统无论如何都会以每个日期一行结束，因此您不妨从一开始就以这种方式设计它，并获得更轻松的数据管理和更快的数据库查询的好处。
关于mysql - 酒店预订系统的价格规则数据库设计，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/33994596/