针对给定情况的最佳数据库模式结构策略

Question

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

（注意：这是我正在做的抽象描述，我正在构建的实际应用程序在结构上非常相似，但不包含我在下面命名的实际组件。）

我正在构建一个包含以下内容的应用程序： 1.客房经理 2.房间 3.嘉宾

每位客房经理都可以选择任意数量的客房进行管理，客人可以报名参加由客房经理管理的客房。客人还可以选择其他客人成为客房内“随行人员”的一部分。我已经勾画出了我正在考虑用于该系统数据库实现的表格图表：

另一个需要注意的重要事项是，这个过程每周会重复一次。经理将挑选房间进行管理，并且客人将报名参加这些房间并带来其他客人的随行人员。因此，随着时间的推移，'managers_rooms'的大小，'guest_reservations'和'guest_entourage'表将增加最快。我想让管理人员能够看到所有已登记进入他们房间的客人以及该客人的随行人员，这意味着我将不得不查询guest_reservations和guest_entourage表（可能是通过连接操作）。

我的问题是：这总体上是一个很好的策略吗？它会随着规模的扩大和增长而引发问题吗？我正在使用带有InnoDB表的MySQL和外键约束+ btree索引，它们是合适的。有什么指针吗？提示？注意事项？谢谢！

EDIT2： 我将使'managers_rooms'表格需要'managers_id，rooms_id和date'的唯一组合作为关键。 'date'使用MySQL DATE字段。

Answer 1

这种结构应该可以正常工作。只需确保在查询条件中的列上有索引，例如日期列。此外，我建议您预先加载具有几百万条记录的测试数据库，并在分析时运行查询。这有助于在早期找到任何缩放问题或缺少索引。

Answer 2

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

一般来说，我会说你的建议应该运作得相当好 - 我建议的唯一一个改进（类似于PPrice）就是如果你确实得到了“期间”的概念 - 例如一周 - 你可能会想要将其建模为数据库中的单独表，并将预留链接到该期间。

这可能会减少查询时日期算术的需要，并增加命中索引的可能性;但是，如果这个“期间”概念确实是核心业务领域实体，我只会这样做。

为了评估您的设计，我会通过业务逻辑思考并制定您最不可能支持的查询 - “查找所有预订客人”，“查找所有预订房间的客人”给经理“，”找到所有未预订的房间“等等，并勾画出你如何使用你的设计实现它们。根据我的经验，90％的查询是显而易见的 - 5％需要一些时间，5％显示数据模型中缺少概念。

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