Mysql 涉及多态关联的复杂时间序列统计聚集

嗯。请容忍我，因为我需要提供大量的上下文细节，然后才能为我的问题寻求合理的答案

我有一个网站，让你每天挑选股票。它的工作方式是，系统会提示您在当天面临竞争的公司之间进行选择。例如，通用电气和IBM。您可以选择两种类型：业绩（哪种股票表现更好？）和总成交量（合并后的股票交易量是否高于或低于X？）。你每天可以得到100美元来挑选

最终，我们的目标是在以下时间段内跟踪不同类别（如下所述）中，每个用户在每次选择中赚的钱最多：5天、15天、30天、90天、180天、1年、所有时间。计算每次采摘能赚多少钱很简单。它是赚（或亏）的总金额/选择数

现在，用户选择的每个公司都属于一个分类层次结构。一般而言，分类层次结构如下所示：

部门-->主要集团-->行业集团-->分类-->公司

以下是一些例子：

• 采矿-->金属采矿-->铁矿石-->褐矿开采-->A公司
• 采矿-->金属采矿-->铁矿石-->褐矿开采-->B公司
• 采矿-->金属采矿-->铁矿石-->褐铁矿开采-->C公司
• 采矿-->金属采矿-->铁矿石-->褐铁矿开采-->D公司
• 制造-->烟草制品-->雪茄-->糖果-->E公司
• 制造-->烟草制品-->雪茄-->糖果-->F公司
• 制造-->烟草制品-->雪茄-->雪茄-->G公司
• 制造-->烟草制品-->雪茄-->雪茄-->H公司
• ……等等

每个类别都有一个模型（当然还有相应的表），它们是关联的（想想外键），就像上面所看到的

有一个配对模型，每个记录代表当天哪些公司要面对。每个记录都记录了每家公司的起始和最终股价，以及总交易量

每场比赛都有一个或多个：提货价格，可以全天变化。通常，每场比赛都有一个性能选择价格和一个总容量选择价格。价格决定了你将花费多少，以及你为一个正确的选择赚多少钱。（现在，这些只是背景信息。你不必担心那些特定的价格计算。）

在交易日结束时，用户的选择被解决。拾取在拾取模型中表示，具有以下属性：

• 用户id
• 花费的金额（如10美元）
• 结果（例如，赢得、失去）
• 挑选（例如A公司）
• 配对id
• 选择\u价格\u id
• 韩元
• 已解决（正确或错误）
• 创建于
• 更新地址

当前，在解析每个拾取时，会更新另一个名为pick_records的表，该表具有以下属性：

• 用户id
• 可记录标识
• 可记录类型（部门或主要集团或行业集团或分类或公司）
• 拾取（所做的总拾取，不考虑拾取类型）
• 赢得（赢得的总拣选数，不考虑拣选类型）
• 丢失（无论拾取类型如何，总拾取丢失）
• 金钱（赢得的总金钱）
• 每支股票的货币（货币/股票）
• 性能测试
• 吴元
• 性能损失
• 业绩与金钱
• 性能(货币)(每支)
• 卷取
• 武元
• 音量丢失
• 货币数量
• 数量(货币)(每支)
• 创建于
• 更新地址

可以看出，这是一个多态模型。该表汇总了所有时间拾取记录统计信息

所以现在的挑战是：

考虑到现有设计，我必须做些什么才能在以下时间段内捕获用户的分拣记录：5天、15天、30天、90天、180天、1年、所有时间段？它需要简单、高效、快速

---

我目前正在MySQL DB上运行Rails 2.3.11。

我认为不需要表拾取记录。
您可以在任意天数内执行类似的查询：

SELECT 
   user_id
   ,sum(amount_spent) 
   ,sum(IF(result = 'WON',1,0)) as WON_count
   ,sum(IF(result = 'LOST',1,0)) as LOST_count
   ,pick 
   /*matchup_id*/
   ,sum(pc.price) as price
   ,sum(IF(result = 'WON'),amount_won,0)) as amount_won
   ,sum(IF(result = 'LOST'),amount_won,0)) as amount_lost
   ,sum(IF(result = 'WON'),amount_won,-amount_won)) as nett_amount
FROM picks
INNER JOIN pick_price pc ON (pc.id = user.pick_price_id)
WHERE created_at BETWEEN DATE_SUB(NOW(), INTERVAL 5 DAY) AND NOW()
  AND resolved = 'true'
GROUP BY user_id, pick

---

我不确定我的问题是否正确，但是

@records=Pick_record.all(:conditions => ["user_id = ?", user_id],
                         :group => "date(created_at)", 
                         :having => ["created_at > ?", 5.days.ago])

---

如果我理解正确的话，现在每个用户只有一个

pick\u记录

，它包含了他的总选择的概述，并在解析选择时更新

由于可以计算

pick_记录的内容

，因此它仅用于缓存并确保您可以真正快速地提供数据/报告

为了解决你的问题，我提出以下建议：

在整个生命周期内，我不会有单一的pick_记录，而是会有您感兴趣的每个时间段的pick_记录。所以你会有一个过去4天的结果的pick_记录，一个是过去14天的结果，29。。。你每天计算一次，最好是在晚上（或者当你的网站使用率低的时候）。当必须显示选定时间段的报告时，您只需添加当天的结果并完成

因此，总结一下：

为每个感兴趣的时段引入一个pick_记录（添加一个字段，指示时段：5、15、30、…）

每天预先计算一次结果（后台工作、e.q.重新确认或延迟的工作）

检索期间结果时，只需添加当天的结果

---

你怎么看？

注意：上面的每个表格都有时间戳-创建时间、更新时间。希望一些答案对你有用；让我知道什么有效，什么无效，这样我就可以给你一个符合你需要的答案。+1表示你在赏金上花了一半的钱。好吧，如果是的话