Как сгруппировать похожие элементы в ленте действий

Для сайта социальной сети у меня есть активность событий от людей, за которыми вы следите, и я хотел бы сгруппировать похожие типы событий, сделанные в короткие сроки, вместе для более компактной ленты активности. Представьте, как Facebook отображает список, разделенный запятыми, когда вам «нравится» несколько вещей в быстрой последовательности: «Джо любит пиво, футбол и чипсы».

Я понимаю, используя метод group_by для результатов ActiveRecord Enumerable, но необходимо выполнить некоторую начальную работу по заполнению свойства, которое я могу сгруппировать позже. Мои вопросы связаны как с хранением данных об активности таким образом, чтобы эти группы можно было пометить, так и с последующим их повторным извлечением.

Прямо сейчас у меня есть модель деятельности, которая представляет собой объединенную ассоциацию между пользователем, совершившим действие, и элемент, с которым он связан (в моем примере выше предположим, что «пиво», «футбол» и «фишки» являются записями модели Like). Помимо лайков, существуют и другие виды активности (события, сохранение избранного и т. Д.). Я рассматриваю то, что при создании этой ассоциации выполняется проверка, когда была выполнена последняя ассоциация этого типа, и если она была сделана более определенного периода времени назад, увеличивается счетчик `` блока активности '', который является частью модели деятельности. Позже, при рендеринге этого канала активности, я могу сгруппировать его по пользователю, затем ввести, а затем этот счетчик блоков активности.

Пример: Допустим, в течение одного дня выполняется 2 блока обновлений. Пользователю нравятся 2 вещи в 2:05 и еще 3 вещи в 5:45. После того, как третье обновление (начало 2-го блока) происходит в 5:45, модель определяет, что прошло слишком много времени, и увеличивает свой счетчик блока активности на 1, тем самым вынуждая любые последующие обновления в новый блок, когда они отображаются через group_by call:

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, поскольку я мог бы легко применить к этому вызов предела, и блоки также могут содержать счетчик автоматического увеличения.