0

我正在为管理全球 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 框架来显示图形信息。

组织需要查看的是其偏远地区的销售数据的每日/每周图表,以及任何“细分”统计数据,例如已售商品(因此您可以“深入”到货币图表中,查看该收入的百分比来自项目 X)。

因此,如果我有 LocationID 的统计信息,那么按大陆组织这些信息是一件相当简单的事情。如果系统需要显示欧洲所有位置的销售数据图表,我可以执行一个查询,为 LocationID 加入一个维度表,该表给出其“大陆”类别,从而(按日期)汇总所有这些数据和将它们显示在图表上。或者,要显示每周信息,请将给定一周内的所有每日报告相加,并将它们作为 JSON 数组返回到我的 JS 图形对象,瞧。据我所知,非常简单的东西。

现在,我的想法是创建这些常见查询的“汇总”表。当用户想要拉起非洲最近 3 个月的销售额,并且查询必须一直深入到每日级别并使用各种 WHERE 和 JOIN 子句时,每周汇总适当的 LocationID 数字,并且然后显示给用户......好吧,拥有一个不太细化的表格似乎更有效。这样的表格需要通过新的每日报告自动更新到主表格中。

以下是需要存在的数据层次结构:

1) 地点的每日数据 2) 大陆的每日数据基于地点的每日数据 3) 星球的每日数据基于大陆的每日数据

4) 地点的每周数据(基于地点的每日数据) 5) 大陆的每周数据(基于地点的每周数据) 6) 地球的每周数据(基于大陆的每周数据)

所以我们这里有一种树,最细粒度的信息在底部(在一个表中,诚然)和一系列越来越细粒度的表,以便更容易获取长期查询的数据(分区如果它接收到地球 3 年每周数据的查询,则按年的每日数据表将毫无用处)。

现在,第一个问题:这有必要吗?在我所描述的场景中,是否有更好的方法来实现广泛的查询效率?


假设没有特别好的方法可以做到这一点,该怎么做呢?

我发现了 MySQL 触发器,在我看来,它似乎能够“级联更新”。在对 Daily Figures 表进行 INSERT 之后,理论上触发器可以读取插入记录的信息,并根据其值对更高级别表的相应记录调用 UPDATE。即,4 月 12 日在乔治亚州制造的 100 美元将提示美国表的“4 月 10 日至 4 月 17 日”记录更新该范围内所有每日记录的总和,这当然会看到新输入的 100 美元和新的值将是正确的。

好的,理论上这是可能的,但它似乎太硬编码了。我想构建系统,以便组织可以添加/删除位置并设置它们所在的大陆,这意味着必须重新配置触发器以包含该 LocationID。无法为给定的命令和表创建多个触发器意味着我必须单独存储触发器数据或从触发器对象中提取它,然后解析输入/输出添加或删除的特定规则,或者保留一个外部在这一步之前我用 PHP 处理的数组,或者......基本上,大量烦人的工作。

虽然 MySQL 触发器最初似乎是我的救星,但我越是了解以我需要的方式实现它们有多棘手,我就越觉得我完全偏离了我的想法,所以我想要从更有经验的数据库人员那里获得一些反馈。


虽然我会很欣赏关于如何完成我正在尝试做的事情的技术建议的智能答案,但我会更深入地欣赏解释正确行动(即使这是我正在做的)以及为什么它是正确的明智答案。

4

0 回答 0