MySQL:在MySQL中存储全年(365个元素)最有效的方式是什么？

Question

在一个项目中，我必须存储不同会议室的每日可用性。假设大约有1.000.000个会议室，每个会议室都在一个城市里，一个城市可能有数百个会议室。

我也希望能够选择进入城市和我需要的可用性，所以我想得到一天的可用会议室的清单，或一组持续的日子，在一个具体的城市。

当我存储城市和会议室名称时，我有一张名为"MeetingRoom“的桌子，但我的设计问题是如何设计可用性部分：

• 根据会议室的可用性，拥有一个存储一年365天的'1‘或'0’的二进制数组，性能会更好吗？
• 在性能方面，是否更好的方法是有另一个名为“可用性”的表来存储一个日期和一点可用性，然后为一个城市中的每个会议室连接这两个表？
• 还有一个我没想过的选择能更好吗？

我想知道，有大约1.000.000个会议室，在城市里搜索会议室，在具体的日子里可以使用，那么查询时间是最理想的。在100 ms以下的数据库响应中进行思考是疯狂的吗？

一些同事告诉我，我也应该考虑迁移到MongoDB或NoSQL方法。我不知道DB的改变是否能更好地适应我的问题，或者它不适合。对此有什么评论吗？

非常感谢您的帮助！！

Answer 1

我不知道这是否有帮助，但如果没有，请写信给我删除答案。

您可以考虑在“可用性”表中只存储房间的id(代理项)和预订日期，而不是这些选项。因此，当您选择数据并连接两个表时，您将只得到预定的房间。我个人认为，没有必要存储所有的房间日期关系与地位。

此外，要提高性能，可以在City列上创建非聚集索引。

Answer 2

请不要用默认值填充数据库中的许多行。

所以你不存储会议室的可用性，而是存储会议室的预订。

预订表的主键是日期和房间id，其他字段是谁预订了这个房间，当预订被要求时，一个预订id.

如果可以预订会议室一天的一部分，那么主键应该是start_date和房间id，结束日期存储在表的另一个字段中。