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

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

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

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

Пользователь A прокомментировал новый альбом пользователя.

  "Hey man nice pictures!"

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

     [show photo thumbnail]

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

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

Источник

4 ответа

Решение

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

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

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

Источник

У меня похожая проблема и похожий вопрос здесь, на Stackru - наши вопросы выглядят почти одинаково:) Проверьте это - получение 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.

Источник

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

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

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

Источник

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

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

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

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

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

Благодарю.

Источник
Другие вопросы по тегам