Добавление каждого поста и события в массив в памяти действительно опасно, не делайте этого!
Я могу придумать 2 решения для вашей проблемы.
1- Самый простой
Добавить дополнительную модель с полиморфной ассоциацией к Посту или Событию и create_at каждый раз, когда вы создаете одну из них.Затем вы можете отсортировать и разбить на страницы эту дополнительную модель на уровне базы данных.Таким образом, у вас не будет проблем с памятью.
У вас может быть какой-нибудь вспомогательный метод для предварительной загрузки записи и событий этого набора результатов, чтобы предотвратить проблему с N + 1 запросами, поскольку вы не можете использовать include / links дляполиморфные ассоциации.
Плюсы: легко реализовать
Минусы: добавлена дополнительная модель, вам необходимо реализовать предварительную загрузку информации, чтобы предотвратить N + 1 запросов, если вам нужно добавить оператор whereвам придется скопировать данные или объединить таблицу с другими.
2- Самое сложное
Используйте запрос UNION с обеими таблицами и возвращайте необходимые поля только для отображенияих.
union_qry = "(SELECT 'Post', id, created_at, '' as title, '' as place FROM posts) UNION (SELECT 'Event', id, created_at, title, place FROM events)"
arr = ActiveRecord::Base.connection.execute("#{search_qry} ORDER BY created_at DESC LIMIT #{per} OFFSET #{offset}") #note the per and offset if you need pagination
Этот запрос вернет MySQL :: Result, который вы можете перебрать, и для каждой записи у вас будет такой массив:
['Post', post_id, post_created_at, '', '']
или
['Event', event_id, event_created_at, event_title, event_place]
С помощью этих массивов вы можете создать свой список событий Post +, если вам нужно больше данных, просто добавьте их в оператор UNION.
Плюсы: нет необходимости в дополнительном элементе, нет необходимости повторятьинформация, вы можете использовать гдев других полях
Минусы: это далеко от ActiveRecord, нет хороших запросов, нет хороших объектов ActiveRecor
Лично я предпочитаю вариант 2, он более гибкий, но вариант 1 проще.