给定情况下的最优数据库模式结构策略

Question

我正在开发一个使用MySQL数据库的独特应用程序，在实现它之前，我正在寻求一些关于我的数据库模式策略的建议。

(注:这是对我所做工作的抽象描述，我正在构建的实际应用程序在结构上非常相似，但不是由我在下面命名的实际组件组成的。)

我正在构建一个应用程序，它将包括: 1.房间经理2.房间3.客人

每个客房经理都可以选择任意数量的房间来管理，客人可以报名入住由客房经理管理的房间。客人也可以选择其他客人作为他们在房间里的“随从”的一部分。我已经勾勒出了我正在考虑用于这个系统的数据库实现的表的图表：

​

​

另一件重要的事情是，这一过程将每周重复一次。经理会挑选房间来管理，客人会报名入住这些房间，并带来其他客人的随行人员。因此，随着时间的推移，“managers_rooms”、“guest_reservations”和“guest_entourage”表的大小将增长最快。我想让经理们能够看到所有报名入住他们房间的客人以及客人的随从，所以这意味着我必须查询guest_reservations和guest_entourage表(大概是通过一个join操作)。

我的问题是:总体来说，这是一个好策略吗?随着规模的扩大，它会不会引发问题？我将MySQL与InnoDB表和外键约束+ btree索引结合使用。有什么指示吗？小费？预防措施？谢谢!

EDIT2: I将使用“managers_id、rooms_id和date”作为键的独特组合来制作“managers_rooms”表。使用MySQL日期字段的“日期”。

Answer 1

“很好”真的很难评估--你提到的唯一标准是可伸缩性。

总的来说，我会说你的建议应该运行得很好--我建议的唯一改进(类似于PPrice)是，如果你确实有“周期”的概念--例如一周--你可能想把它建模成数据库中的一个单独的表，并将预订链接到那个时间段。

这可能减少查询时对日期算法的需求，并增加命中索引的可能性；不过，只有当这个“时间段”概念确实是一个核心业务域实体时，我才会这样做。

为了评估您的设计，我会通过业务逻辑考虑，并起草您最有可能支持的查询--“为客人查找所有预订”、“查找所有从给定经理那里预订房间的客人”、“查找所有未预订的房间”等，并勾勒出如何使用您的设计来实现它们。根据我的经验，90%的查询是显而易见的-- 5%的查询需要一些时间，5%的查询在数据模型中显示出缺失的概念。

我还会考虑其他评估标准--可维护性经常被忽略。

Answer 2

这种结构应该工作得很好。只需确保在查询条件中的列(如日期列)上有索引。此外，我建议您预先加载一个包含数百万条记录的测试数据库，并在分析时运行您的查询。这将有助于在早期发现任何缩放问题或缺少索引。