Для сайта социальной сети у меня есть активность событий от людей, которых вы придерживаетесь, и я хотел бы группировать подобные типы событий, сделанные в короткие промежутки времени, для более компактный поток активности. Представьте, как Facebook отображает список, разделенный запятыми, когда вам нравится «несколько вещей в быстрой последовательности:« Джо любит пиво, футбол и фишки ».Как группировать похожие элементы в фиде активности
Я понимаю, используя метод group_by в ActiveRecord Перечислимые результаты, но должна быть начата некоторая начальная работа, заполняющая свойство, которое я могу группировать позже. Мои вопросы касаются как хранения данных активности таким образом, что эти группировки могут быть отмечены, а затем позже получать их снова.
Сейчас у меня есть модель действия, которая представляет собой ассоциацию соединения между пользователем, совершившим действие и элемент, с которым он связан (в моем примере выше, предположим, что «пиво», «футбол» и «фишки» - являются записями модели Like). Существуют и другие виды активности, кроме «симпатий» (события, сохранение избранных и т. Д.). Что я рассматриваю, так как эта ассоциация создается, проверка выполняется, когда была выполнена последняя ассоциация этого типа, и если она была сделана более определенного периода времени назад, увеличивая счетчик «блок активности», который является частью модели деятельности. Позже, создавая этот фид активности, я могу группировать по пользователю, а затем набирать, а затем этот счетчик активности.
Пример: предположим, что в тот же день сделано 2 блока обновлений. Пользователю нравится 2 вещи в 2:05, а затем еще 3 вещи в 5:45. После того, как третье обновление (начало второго блока) произойдет в 5:45, модель обнаруживает слишком много времени и увеличивает счетчик блоков активности на 1, тем самым заставляя любые последующие обновления в новый блок, когда они отображаются через 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, поэтому самая легкая вещь, о которой я могу думать, смотрит на счетчик для последней записи в качестве контрольной точки. Однако это не может быть из того же запроса, который проверял, когда было произведено последнее обновление этого типа, поскольку более позднее обновление другого типа могло уже получить следующее значение счетчика. Им не обязательно быть глобально уникальными, но это было бы неплохо.
Другая общая стратегия, о которой я думал, была другой моделью Called ActivityBlock, которая объединяет группы подобных действий. Во многих случаях обновления будут изолированы сами по себе, так что это кажется немного неэффективным, чтобы иметь одну запись для каждой отдельной деятельности.
Действительно ли какая-либо из них кажется надежной стратегией?
Мой последний вопрос вращается вокруг разбиения на страницы. Теперь, когда мы имеем дело с блоками, сложнее всегда отображать точно определенное количество записей, прежде чем разбивается страница. Либо индивидуальное (изолированное) обновление активности, либо блок затем должно считаться как 1, поэтому на самом низком слой моей group_by, я могу включить счетчик для отслеживания количества строк, которые я отобразил, но это означает, что я не могу просто просто выполнить один запрос БД и просто указать оператор ограничения. Есть ли способ сделать это без повторного выполнения дополнительных SQL-запросов, пока я не достиг предела моей страницы?
Это было бы одним из преимуществ подхода модели ActivityBlock, поскольку я мог бы легко применить к нему лимитный вызов, а блоки могут также содержать счетчик автоматического увеличения.
Привет Joost, Можете ли вы поделиться модель данных для все, что вы сделали? Я имею в виду, как вы храните действия для каждого пользователя? Спасибо – Imran
Любое решение о том, что лучший способ пойти? – MonkeyBonkey
Я отложил этот проект на данный момент и не экспериментировал с этим конкретным аспектом. –