База данных и дизайн ленты новостей PHP

Я разрабатываю систему новостей с использованием PHP / MySQL, аналогичную facebook.

Я задал аналогичный вопрос раньше, но теперь я изменил дизайн и я ищу обратную связь.

Пример Новости:

User_A прокомментировал Пользователь_вновое альбом. 

  "Hey man nice pictures!"

Пользователь_в добавлен новый фото в [его/ее] профиль.

     [show photo thumbnail]

Первоначально я реализовал это, используя чрезмерные столбцы для Obj1:Type1 | Obj2: Type2 | etc..

Теперь дизайн настроен с использованием пары специальных ключевых слов и отношений актера/приемника. Моя база данных использует таблицу сообщений, объединенных в таблицу, содержащую userid, actionid, 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 = владелец принимающего объекта (например, владелец альбома) (NULL, если %r является пользователем)

вопросы:

  1. Это умный (эффективный/масштабируемый) способ двигаться вперед?

  2. как я могу сохранить "предварительный просмотр события"? Например, если я хочу показать комментарий, который User_A сделал User_B (как указано выше, и в ленте новостей facebook). Я рассмотрел возможность использования закодированной копии только соответствующих данных.. например, JSON кодирует текст комментария или фотографию html.. но это кажется хрупким (пользователь может удалить фотографию, пока она все еще находится в ленте другого пользователя)

  3. как я могу показать сообщения, такие как: "User_B добавил 4 новых фото к своему профиль.- с миниатюрами фотографий?

13
mysql news-feed performance php social-networking

4 ответов

построив что-то подобное совсем недавно, я бы предложил отделить идею о том, как хранить данные от производительности. В моем случае пользователи должны иметь возможность вернуться и посмотреть новости из любого периода времени, поэтому предположения арнорха не работают (независимо от того, нет причин хранить HTML, если вам не нужно-оставьте форматирование снаружи).

Я обнаружил, что я храню материал в нескольких классах,ActivityType и Activity. ActivityType держит формат сообщения (например,'%a commented on %o's new %r') и показатель того, представляет ли он фактическую деятельность или комментарий к чьей-либо деятельности (поэтому я знаю, какой объект для ссылки, деятельность актера или актер деятельности прокомментировал) и Activity сохраняет субъекта, жертву, первичный ключ объекта, первичный ключ к комментируемому объекту, если он существует, и метку времени, когда это произошло.

что все отлично и приводит к красиво нормализованным данным. Который еле сканирование, как только у вас есть полдюжины друзей (производительность осложняется тем, что все это основано на местоположении, поэтому я смотрю на расстояние, которое каждый пользователь находится от вас). Все ищут предлог, чтобы играть с системами хранения NoSQL сейчас, но это на самом деле хороший. Вам придется де-нормализовать данные, чтобы получить достойную производительность из реляционной базы данных. И материал трудно кэшировать из-за различных пересечений отношений. Думать о хранении данных в MySQL, но получении их обратно из системы хранения NoSQL.

10

У меня аналогичная проблема и аналогичный вопрос здесь, на StackOverflow - наши вопросы выглядят почти одинаково :) проверьте это - получение дерева данных JSON из MySQL

но я пытаюсь решить проблему немного по-другому: я создаю объекты JSON. Поэтому моя таблица новостей выглядит так:

news_type   | datetime_added  | params
------------+-----------------+--------------------------------------------------------
new_photos  | 2010.12.01      | {user_id: "12", photo_id: "26", photo_url: "/images/photo.jpg"} 
new_comment | 2010.12.01      | {owner_id: "12", photo_id: "26", photo_url: "/images/photo.jpg", commenter_id: 25, comment_text: "Nice!"}

затем я использую json_decode в php для создания массивов. Затем в зависимости от news_type я создаю необходимый HTML.

3

  1. Да, это способ двигаться вперед с этим. Это сообщения, которые живут очень короткое время, поэтому вам никогда не придется обновлять их во времени, если вы внесете изменения в HTML сообщения, которое вы храните и т. д. Таким образом, вы должны быть в хорошей форме, используя это.

  2. просто используйте простой HTML. Это будет быстро, и нет никаких отношений, которые вам придется применять позже, вам никогда не придется обновлять их или что-то вроде что.

Edit: я действительно неправильно понял, я не знал, что вы предполагали, что эти %s-вещи будут какой-то специальной нотацией для объектов, на которые вы ссылаетесь. Я бы просто разместил простые уведомления HTML в этом тексте.

1

когда вы говорите в отношении Facebook, вы должны думать об отправителе и получателе.

скажите, когда вы хотите увидеть все сообщения / каналы в B? тогда вы должны запустить запрос правильно? Я думаю, что ваша таблица кажется прекрасной,но также добавьте столбец для идентификатора получателя. Может быть, вы можете сохранить это в отдельной таблице.

, Так что вы можете легко найти все ленты для пользователя B или от пользователя B или от пользователя A к пользователю B

надеюсь, что это может быть, это вам поможет.

но игнорируйте это, если вы хотите сосредоточиться только на кормах. тогда вам нужны только последние. То, что я думал, это w.r.т. facebook, где мы можем увидеть чей-либо профиль со стенами, которые он получил от diff. пользователи.

спасибо.

0