项目结构和绩效

时间:2011-09-19 11:38:35

标签: mysql database data-structures

我即将开始一个新的网络项目,我有点坚持如何构建整个事物以获得最佳性能,希望有人可以帮助我。我将使用MySQL用PHP编写它。

整个事情将是一个自动预订系统,客户可以在某些日子预订,有点像航空公司的系统。所以会有很多预定的活动(例如每个星期一,星期五从3月到9月),一些例外(例如2月份的单个活动)。这些预定的活动将有一些不同的“主题”,具有不同的定价,具体取决于主题和日期(例如3月至4月便宜,5月至9月价格昂贵)。一切都应该是可以改变的(例如价格,时间表,最大参与者)

我考虑创建三个表:

  • 活动[关于日程安排日期,价格和最大参与者的信息]
  • 客户[客户信息和对活动ID /预订ID的引用]
  • 预订[包含每天参与者的数量(参考活动和客户)以及可能的例外情况,如价格变化,参与者限制等等)

希望不要弄清楚我在这里尝试的是什么...... 我正在尝试只关注日历上的速度,该日历检查预订表并输出是否已经完全预订了日期[具有事件表的预订表]以及当前价格是多少。管理面板也应该非常快,因此很容易列出所有预订或访问某一天。

现在让我们来看看真实的东西...... 也许我采用错误的方法以这种方式分割数据,但是当涉及批量更改时显然存在一些缺陷,因为我必须在预订表中插入许多异常或为事件创建新条目并更改旧的一,在我眼中有点乱(特别是当你有一些例外)。无论如何,我最终会有大量的条目,而我实际上想要保持系统更加自动化,就像只有几个时间表并让PHP完成剩下的工作(猜测它比查询MySQL更快)。

那你觉得怎么样?我无法想出任何其他数据分离。最简单的代码可能是为每天和每个事件实例化一个数据库条目,但我想我母亲可以说这是蹩脚而且缓慢。

1 个答案:

答案 0 :(得分:0)

总的来说,我同意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),如果您真的关心性能,请使用示例数据填充数据库,并调整查询期待需要。

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