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

Question

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

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

Пример News:

User_A прокомментировал User_B новый альбом .

  "Hey man nice pictures!"

Пользователь_B добавил новую фотографию в [его / ее] профиль .

     [show photo thumbnail]

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

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

Вот сокращенная версия того, как это будет выглядеть после присоединения:

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. Как я могу показывать сообщения типа: "Пользователь_B добавил 4 новые фотографии к своему профиль. "с миниатюрами фотографий?

Answer 1

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

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

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

Answer 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.

Answer 3

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

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

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

Answer 4

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

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

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

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

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

спасибо.