项目结构和绩效

Question

我即将开始一个新的 Web 项目，但我对如何构建整个项目以获得最佳性能有点困惑，希望有人能在这里帮助我。我将使用 MySQL 使用 PHP 编写它。

整个过程将是一个自动预订系统，客户可以在其中预订特定日期，有点像航空公司的系统。所以会有很多预定的活动（例如，从 3 月到 9 月的每个星期一、星期五），少数例外（例如 2 月的单个活动）。这些预定的活动将有几个不同的“主题”，根据主题和日期不同定价（例如，3 月至 4 月便宜，5 月至 9 月昂贵）。一切都应该是可变的（例如价格、时间表、最大参与者）

我想过创建三个表：

• 活动[有关日程安排天数、价格和最大参与者的信息]
• 客户 [客户信息和对活动 ID/预订 ID 的引用]
• bookings [包含每天的参与者数量（参考活动和客户）以及可能的例外情况，例如价格变化、不同参与者限制等]

希望这不是不清楚我在这里尝试什么... 我试图只关注日历上的速度，它检查预订表并输出当天是否已经预订完毕[带有事件表的预订表]以及当前价格是多少。不过，管理面板也应该很快，以便列出所有预订或访问某一天。

现在让我们来看看真正的东西...... 也许我采取了错误的方法来以这种方式拆分数据，但是在批量更改方面显然存在一些缺陷，因为我必须在预订表中插入许多异常或为活动创建新条目并更改旧的一，在我看来有点乱（特别是当你有多个例外时）。无论如何，我最终会得到大量条目，而我实际上希望将系统维护得更加自动化，比如只需要一些计划并让 PHP 完成其余的工作（猜想这比查询 MySQL 更快）。

那你怎么看？我想不出任何其他的数据分离。最简单的编码可能是为每一天和每一个事件实例化一个数据库条目，但我想我妈妈可以看出这是蹩脚和缓慢的。

Answer 1

总的来说，我同意 Colin Fine 的建议，即让数据结构清晰且合乎逻辑，然后再担心性能问题 - 优化结构良好但速度较慢的数据库比维护过早优化的数据库容易得多.

话虽如此，您的问题并不完全清楚 - 但我会冒险提出以下想法。

首先，您的“事件”和“例外”概念听起来像是属于同一类——我不会将它们放在预订中。事实上，我认为“预订”是活动和客户之间的交集，以及附加信息（例如状态、付款详情等）。

其次，您似乎担心要创建的事件数量；我不认为你需要。即使每天有 10 个事件，并且您提前 10 年安排，您仍然只处理几万条记录 - 这远不及 MySQL 的限制。此外，数据库中的查找将比 PHP 中与异常查找相关联的复杂逻辑更容易维护（而且可能更快）。

所以，我会考虑创建以下表格：

EventType

ID Description     Duration    Price
------------------------------------
1   1 day event          1       10
2   2 day event          2       15

EventInstance

ID  EventTypeID  StartDate   EndDate      Duration    Price
1   1            1 Jan 2012  2 Jan 2012          1       10 //Regular event
2   1            1 Feb 2012  2 Feb 2012          1       20 //Special price exception
3   1            1 Mar 2012  3 Mar 2012          2       25 //Special duration and price exception

您可以通过遍历所需的任何日期逻辑来填充“EventInstance”表，然后自定义“异常”记录

这样，“1 月 1 日发生了什么”问题可以通过单个数据库查询来回答，而不是用逻辑来检查 1 月 1 日是星期一、一个月的第一天、闰年还是任何。

我强烈建议按照数据库设计的神圣原则创建一个基本数据模型（将上限交给圣徒 Codd），如果您真的关心性能，请使用示例数据填充数据库，并调整您的查询期望需要。

通过处理实际数据并对其进行优化，您将获得更好的信息和更准确的结果，而不是在项目的早期阶段担心总体性能。