Mysql 数据库设计销售报告答案

【问题标题】：Mysql Database design for sale reportsMysql 数据库设计销售报告
【发布时间】：2020-11-28 21:22:42
【问题描述】：

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

这里是场景。我有 10 万多个用户，每个用户每天进行 0 次或更多次销售。如果她/他的销售额为 0，则当天不会为该用户存储任何内容，否则如果她/他的销售额超过一次，则当天的销售额将增加 1。

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

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

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

所以我想问的确切问题是，我是否可以再创建三个表来保存每周、每月和每年的记录，这将允许我做两件事，我可以删除每日销售数据，比如超过 2 个月，而且我仍然可以访问用户的每周、每月等销售记录，因为这些表的清除可以设置为，例如 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 进一步减少对这些表的读取。

我看到这种方法的缺点是，我必须运行 4 个查询来记录单个销售计数器，而不是一个，因为每个表的计数器必须单独递增。

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

谢谢

【问题讨论】：

单表对我来说似乎是正确的方法
感谢您的回答，但可以解释原因吗？而且，多表方法会有什么问题？
您正在通过创建不必要的冗余来解决一个问题（不存在）
很公平。但是假设它确实存在，那应该是什么方法呢？
1800 万条记录，具有适当的索引和数据类型，应该不是问题。

标签： database-design

【解决方案1】：

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

创建一个表以保留您将来要使用的最小周期单位。
创建 crontab 或触发器或任何东西来计算销售额并按用户 ID 在该表上分组，您可以在一天结束或一周结束时计算它，尝试找到最佳方法。
当你想显示那个计数器时，你可以从那个表中选择，再次按用户 ID 分组，它会比事务表上的计数更轻。

【讨论】：