Mysql 销售报告的数据库设计

Question

所以我一直坚持如何为这个销售报告设计我的数据库。

场景如下。我有 100K+ 用户，每个用户每天进行 0 次或更多次销售。如果 s/he 的销售额为 0，那么当天不会为该用户存储任何内容，否则如果 s/he 的销售额不止一次，那么它只会在当天增加 1。

现在的问题是关于数据库设计（重点是最终性能）。一种简单的方法是只创建一个带日期的 table 和 user_id 并使用 WHERE 子句来获取给定用户的每周、每月和每年的销售业绩。

Table: user_sales_counter
--------------------
user_id, sales, date

但是，我在这里看到的问题是，如果六个月后，我想查找某个用户特定周的报告，那么在最坏的情况下我将不得不遍历 1800 万条记录。

所以我想问的确切问题是，我可以再创建三个 tables 用于每周、每月和每年的记录保存，这将允许我做两件事，我可以删除每日销售数据，比如说超过 2 个月，我仍然可以访问用户的每周、每月等销售记录，因为可以将这些 table 的清除设置为例如 1 年或更久。

Table: weekly_sales_counter
---------------------------
week_no, month_no_year, user_id, sales

Table: monthly_sales_counter
----------------------------
month_no_year, user_id, sales

Table: yearly_sales_counter
---------------------------
year, user_id, sales

我正在使用 Redis 进一步减少对这些 table 的读取。

我看到这种方法的缺点是，我必须运行 4 次查询才能记录一个销售柜台，因为每个 table 的柜台都必须是分别递增。

最好的方案是什么？单table还是第二个？或者您有其他我可以采用的方法吗？

谢谢

Answer 1

根据我的经验，从交易的百万数据中查询将需要越来越长的时间。我的建议是：

创建一个 table 以保留您将来要使用的最小周期单位。
创建 crontab 或触发器或任何东西来计算销售额和按用户 ID 分组 table，您可以在一天结束时或一周结束时计算它，尝试找到最好的方式。
每当你想显示那个计数器时，你可以只从那个 table 中 select，再次按用户 ID 分组，它会比交易 table 上的计数更轻.

Mysql 销售报告的数据库设计

Mysql Database design for sale reports

database-design