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

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

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

Пример новостей:

User_A прокомментировал User_B новый альбом.
  "Hey man nice pictures!"
Пользователь_B добавил новый профиль Фото в [свой] .
     [show photo thumbnail]

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

Теперь дизайн настраивается с использованием нескольких специальных ключевых слов и отношений с актерами/получателями. Моя база данных использует таблицу сообщений, соединенную с таблицей, содержащей идентификаторы пользователя, actionid, receiverid, receiverObjectTypeID,

Здесь сжатая версия того, как она будет выглядеть, когда-то соединялась:

News_ID | User_ID |                  Message                   |     Timestamp

  2643       A       %a commented on %o new %r.                  SomeTimestamp
  2644       B     %a added a new %r to [his/her] profile.         SomeTimestamp

% a = User_ID человека, выполняющего действие

% r = принимающий объект

% o = владелец получающего объекта (например, владелец альбома) (NULL, если% r является пользователем)

Вопросы:

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

Ответ 1

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

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

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

Ответ 2

У меня аналогичная проблема и аналогичный вопрос здесь, на 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

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

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

Ответ 4

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

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

Чтобы вы могли легко найти все фиды для пользователя B ИЛИ от пользователя B ИЛИ от пользователя A до пользователя B

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

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

спасибо.