对于社交网站，我有来自您关注的人的活动活动，并且我想在短时间内将类似类型的活动分组在一起，以获得更紧凑的活动供稿。想象一下，当你快速接受几件事时，Facebook如何显示逗号分隔列表：'乔喜欢啤酒，足球和筹码。'
我理解在ActiveRecord Enumerable结果中使用group_by方法，但是需要完成一些初始工作，填充我以后可以分组的属性。我的问题涉及以可以标记这些分组的方式存储活动数据，然后再次检索它们。
现在我有一个Activity模型，它是提交活动的用户和它链接到的项目之间的连接关联（在上面的例子中，假设'beer'，'football'和'chips'是Like模型的记录）。除了“喜欢”之外还有其他活动类型（活动，保存收藏夹等）。我正在考虑的是，随着这个关联的创建，在完成该类型的最后一次关联时进行检查，如果超过某个时间段，则增加一个“活动块”计数器，这是一部分活动模型。稍后，在渲染此活动供稿时，我可以按用户分组，然后键入，然后输入此活动阻止计数器。
示例：假设在同一天内发布了2个更新块。用户在2:05喜欢2件事，之后在5:45喜欢3件事。在第三次更新（第二个块的开始）发生在5:45之后，模型检测到已经过了太多时间并且将其活动块计数器递增1，因此当通过a渲染它们时强制任何后续更新到新块中group_by电话：
2:05 Joe likes beer nuts and Hooters.
5:45 Joe likes couches, chips and salsa.
7:00 Joe is attending the Football Viewing Party At Joe's
我的第一个问题：增加这样一个计数器的有效方法是什么？它不再是auto_increment，所以我能想到的最简单的事情是将最后一条记录作为参考点。但是，这不能来自检查该类型的最后一次更新的同一查询，因为稍后更新另一种类型可能已经接收到下一个计数器值。它们不一定是全球唯一的，但那样会很好。
我想到的另一个整体策略是另一个名为ActivityBlock的模型，它将类似活动的组合在一起。在许多情况下，更新将自行隔离，因此为每个单独的活动创建一条记录似乎效率不高。
这些中的任何一个看起来都是一个可靠的策略吗？
我的最后一个问题围绕着分页。既然我们正在处理块，那么在分页开始之前总是显示一定数量的条目就更难了。个别（隔离的）Activity更新或者当时的块应该只计为1，所以最低我的group_by的一层，我可以合并一个计数器来跟踪我显示的行数，但这意味着我不能只进行一次数据库查询而只需指定一个限制语句。在我达到页面限制之前，有没有办法在不重复执行其他SQL查询的情况下仍然可以执行此操作？
这将是ActivityBlock模型方法的一个优点，因为我可以轻松地对其应用限制调用，并且块也可以包含自动增量计数器。
答案 0 :(得分：1)
结帐http://railscasts.com/episodes/406-public-activity 他还在第407集中发布了一篇关于如何从零开始做的事情（虽然这是专业插曲）。
答案 1 :(得分：0)
您可以使用纪元时间或其变体作为计数器，因为那是半独特的和确定性的