База данных ленты новостей PHP и дизайн
Я разрабатываю систему ленты новостей с помощью PHP/MySQL, подобного Facebook.
Я задал подобный вопрос прежде, но теперь я изменил дизайн, и я ищу обратную связь.
Example News:
User_A прокомментировал новый альбом User_B.
"Hey man nice pictures!"User_B добавил новую фотографию к [его] профилю.
[show photo thumbnail]
Первоначально, я реализовал этот использующие чрезмерные столбцы для Obj1:Type1 | Obj2:Type2 | и т.д.
Теперь дизайн настраивается с помощью пары специальных ключевых слов и отношений агента/получателя. Моя база данных использует таблицу сообщений, к которым присоединяются на таблице, содержащей идентификатор пользователя, возбудил уголовное дело, receiverid, receiverObjectTypeID,
Вот сжатая версия того, на что она будет похожа когда-то присоединенный:
News_ID | User_ID | Message | Timestamp
2643 A %a commented on %o's new %r. SomeTimestamp
2644 B %a added a new %r to [his/her] profile. SomeTimestamp
%a = User_ID человека, делающего действие
%r = принимающий объект
%o = владелец принимающего объекта (например, владелец альбома) (ПУСТОЙ УКАЗАТЕЛЬ, если %r является пользователем),
Вопросы:
Действительно ли это - умный (эффективный/масштабируемый) способ продвинуться?
Как я могу сохранить "Предварительный просмотр события"? Например, если я хочу показать комментарий, что User_A сделал к User_B (как вышеупомянутый, и на ленте новостей Facebook). Я рассмотрел использование закодированной копии только соответствующих данных.. например, JSON кодирование HTML текста комментария или фотографии.. но это кажется хрупким (пользователь может удалить фотографию, в то время как это находится все еще в канале других пользователей),
Как может я показывать сообщения как: "User_B добавил 4 новых фотографии к его профилю". с миниатюрами фотографий?
3 ответа
Создав что-то подобное совсем недавно, я бы посоветовал отделить идею хранения данных от производительности. В моем случае у пользователей должна быть возможность вернуться и посмотреть новости за любой период времени, поэтому предположения arnorhs не работают (несмотря на это, нет причин хранить HTML, если вам не нужно - оставьте форматирование снаружи).
Я обнаружил, что храню данные в нескольких классах: ActivityType и Activity . ActivityType содержит формат сообщения (например, ваш '% a прокомментировал новый% r' % o) и индикатор того, представляет ли оно фактическую активность или комментарий к чьей-либо деятельности. (так что я знаю, на какой объект ссылаться, действие актера или актера комментируемого действия) и Activity хранит актера, жертву, первичный ключ объекта, первичный ключ к комментированному объект, если он существует, и отметку времени, когда это произошло.
Что очень хорошо, так как в результате получаются хорошо нормализованные данные. Что замедляется до ползания, как только у вас появляется полдюжины друзей (производительность усложняется тем, что все зависит от местоположения, поэтому я смотрю расстояние, на котором каждый пользователь находится от вас). Сейчас все ищут повод поиграть с системами хранения NoSQL, но на самом деле это хороший повод. Вам придется чертовски денормализовать данные, чтобы получить достойную производительность от реляционной базы данных. И этот материал сложно кэшировать из-за различных пересечений отношений. Подумайте о том, чтобы хранить данные в MySQL, но вернуть их из системы хранения NoSQL.
Да, это лучший способ двигаться вперед. Это сообщения, которые живут очень короткое время, поэтому вам никогда не придется обновлять их во времени, если вы внесете изменения в HTML сохраняемого сообщения и т. Д. Таким образом, вы должны быть в хорошей форме, используя это.
Просто используйте простой HTML. Это будет быстро, и вам не придется устанавливать какие-либо связи позже, вам никогда не придется обновлять их или что-то в этом роде.
Редактировать: Я на самом деле неправильно понял, я не знал, что вы предназначаете эти% s-вещи для обозначения каких-то объектов, на которые вы ссылаетесь. Я бы просто поместил в этот текст обычные HTML-уведомления.
Когда вы говорите о Facebook, вы должны думать об отправителе и получателе.
Скажите, когда вы хотите видеть все сообщения / каналы для B? тогда вы должны запустить запрос, верно? Я думаю, что ваша таблица выглядит нормально, но также добавьте столбец для идентификатора получателя. Может быть, вы можете оставить это в отдельной таблице.
Чтобы вы могли легко найти все каналы для пользователя B ИЛИ от пользователя B ИЛИ от пользователя A к пользователю B
надеюсь, что это может быть вам полезно .
Но не обращайте на это внимания, если вы хотите сосредоточиться только на каналах. тогда вам нужны только самые свежие. Я думал, что это w.r.t. facebook, где мы можем увидеть чей-либо профиль со стенами, полученными от diff. пользователей.
спасибо.