В долгосрочной перспективе я не уверен, что предложенная вами схема даст вам большую гибкость:
Схема БД - это то, что я ищу. Я подумал, может быть, что-то вроде .... Activity_id Activity_message Activity_time Где сообщение будет что-то вроде "{USERID: 34} лайков {USERID: 23} пост" и "{USERID: 34} изменил свою фотографию {PHOTOID: 2}"
Проблема в том, что вы полагаетесь на регулярные выражения и другие дорогостоящие (вовремя) методы анализа этого для отображения.
Возможно (мне никогда не приходилось проектировать подобные вещи), если у вас есть отдельная таблица для «лайков», в которой есть user.id, post.id, timestamp, вы можете затем для конкретного поста легко сосчитать количество людей, которым это нравится, для потока активности вы можете фильтровать по пользователю и заказывать по времени. Сохраненный user.id - это человек, которому понравилось сообщение, и вы можете присоединиться к post.id, чтобы связать пользователя с этим сообщением.
Для работы с изображениями и / или другими взаимодействиями у вас может быть таблица, содержащая, user.id, item.id, action, timestamp, где item.id - это ссылка на рисунок / post / other id, а действие - числовое идентификатор, соответствующий действию, которое вы затем можете связать со строкой.
Поступая таким образом, вы получаете другие преимущества, заключающиеся в том, что если вы хотите использовать несколько языков позже или решите изменить термин «нравится» на «наслаждается», вы можете легко сделать это так, как если бы вы хранили текстовую строку, которая позже будет показано, что вам будет труднее заменить его.