我为销售组织设计了一个统计跟踪系统，该系统管理着全球300多个远程销售点。系统会收到有关销售数据的每日报告（原始美元价值和信息统计数据，例如X商品的销售数量等）。
我正在使用MAMP来构建系统。
我计划将这些数据存储在一个MySQL大表中，因此每一行都是来自一个位置的一天统计信息。这是一个示例：
------------------------------------------------------------------
| LocationID | Date | Sales$ | Item1Sold | Item2Sold | Item3Sold |
------------------------------------------------------------------
| Hawaii | 3/4 | 100 | 2 | 3 | 4 |
| Turkey | 3/4 | 200 | 1 | 5 | 9 |
------------------------------------------------------------------
由于该组织可能每天都会从300个地点的每个地点收到统计信息更新，因此我估计在一个月内该表将有9,000条记录，一年内将有108,000条记录。因此，基于年份的MySQL表分区应该将查询保持在100,000记录范围内，我认为这样可以在一段时间内保持稳定的性能。
（如果有人发现上述背景数据中的理论存在问题，请随意提及它们，因为我没有建立大型数据库的经验，这就是我收集的内容在网上搜索。）
现在，在这个系统的前端，它是基于Web的，主要关注PHP。我打算使用我在网上找到的YUI框架来显示图形信息。
组织需要看到的是他们的远程位置的销售数据的每日/每周图表，以及任何＆＃39;细分＆＃39;销售物品等统计数据（因此您可以＆＃34;向下钻取＆＃34;进入货币图表，看看该项收入的百分比来自项目X）。
因此，如果我有LocationID的统计数据，那么按大陆组织这些信息就相当简单了。如果系统需要显示欧洲所有地点的销售数据图表，我可以执行一个查询，该查询为位置ID加入一个维度表，该ID表示其＆＃34;大陆＆＃34;类别，从而将所有这些数字相加（按日期）并在图表上显示。或者，要显示每周信息，请将给定周内的所有每日报告求和，并将它们作为JSON数组返回到我的JS图形对象，瞧。就我所见，这非常简单。
现在，我的想法是创建＆＃34;摘要＆＃34;这些常见查询的表格。当用户想要提取非洲的最近3个月的销售额时，查询必须一直下降到每日级别并且使用各种WHERE和JOIN子句，总结相应的LocationID的数据。每周一次，然后显示给用户...好吧，拥有一个不太精细的表似乎更有效。这样的表需要通过新的每日报告自动更新到主表中。
这里是那种需要存在的数据层次结构：
1）按地点划分的每日数字 2）大陆每日数据基于位置的每日数据 3）基于大陆每日数据的行星每日数据
4）按地点划分的每周数字位置 5）每周数据按大陆基于每周位置数字 6）基于大陆每周数据的星球每周数据
所以我们在这里有一种树，底部有最细粒度的信息（在一个表中，不可否认）和一系列越来越细化的表，以便更容易获取长期查询的数据（按年划分每日数字表将无用，如果收到地球每周3年数据的查询）。
现在，第一个问题：这有必要吗？在我描述的场景中是否有更好的方法来实现广泛的查询效率？
假设没有特别好的方法可以做到这一点，那该怎么办呢？
我发现MySQL触发器，对我来说似乎能够级联更新＆＃39;原样。在INSERT进入每日数字表后，触发器理论上可以读取插入记录的信息，并根据其值，在更高级别表的相应记录上调用UPDATE。也就是说，4月12日在格鲁吉亚制造的100美元将促使美国的桌子在4月10日至4月17日期间推出。使用该范围内所有日常记录的SUM记录到UPDATE，这当然会看到新输入的$ 100，新值将是正确的。
好的，这在理论上是可行的，但似乎太难编码了。我想构建系统，以便组织可以添加/删除位置并设置它们所在的大陆，这意味着必须重新配置触发器以包含该LocationID。无法为给定的命令和表创建多个触发器意味着我必须单独存储触发器数据或从触发器对象中提取它，然后解析/删除正在添加或删除的特定规则，或者保持外部我在此步骤之前使用PHP处理的数组，或者......基本上是一大堆烦人的工作。
虽然MySQL触发器最初看起来像是我的救赎，但我越是关注以我需要的方式实现它们是多么棘手，似乎我已经越来越完全我是如何做到的，所以我想从更有经验的数据库人那里得到一些反馈。
虽然我很欣赏有关如何完成我想要做的事情的技术建议的智能答案，但我会更加深刻地理解能够解释正确行动的明智答案（即使它是我的＆＃39） ;我在做什么）以及为什么它是正确的。