Предложения по изменению моей таблицы обновлений в социальной сети?

Поскольку я продолжаю работать над своим сайтом в социальной сети (которую я, вероятно, никогда не закончу), я решил, что мне, вероятно, следует пересмотреть свою таблицу «Обновления». Если вы думаете об этом как о Facebook, в таблице «Обновления» хранятся истории для новостной ленты, например, User_123 изменил свой статус, или SomeOtherUser добавил новое фото/видео, или YetAnotherUser присоединился к группе.

Моя текущая структура таблицы выглядит следующим образом:

ОБНОВЛЕНИЯ

PK Update_ID
Тип
Update_Content
FK Photo_ID
FK Video_ID
FK Owner_ID
FK Group_Wall_ID
FK Friend_Wall_ID
голоса "за"
голоса "против"
отметка времени


В качестве примечания, тип относится к типу обновления (1 – обновление статуса, 2 – пользователь присоединился к группе, 3 – новая фотография и т. д.), а Update_Content – текст статуса или сообщение вида "Пользователь_123 присоединился к группе"

Прямо сейчас, как у меня, когда пользователь публикует обновление на своей «стене», Group_Wall_ID и Friend_Wall_ID по умолчанию равны 0. Принимая во внимание, что если этот пользователь публикует обновление в группе, Group_Wall_ID имеет значение, а Friend_Wall_ID — нет.

Кроме того, если обновление является только обновлением статуса, Photo_ID и Video_ID по умолчанию равны 0. Однако, если обновление представляет собой новую фотографию, Photo_ID будет иметь значение, соответствующее PK в таблице Photos.

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


mysql database relational-database foreign-keys
person HockeyRef45    schedule 24.12.2012    source источник
comment
обязательно ли для этого использовать реляционную базу данных?   -  person Trent Earl    schedule 24.12.2012
comment
@TRENT это не требование, но до сих пор я его использовал.   -  person HockeyRef45    schedule 24.12.2012

Ответы (1)


arrow_upward
0
arrow_downward

Я не думаю, что это приложение хорошо подходит для MySQL. С MySQL вы собираете все ресурсы вместе при каждом чтении. Также не кажется, что поток должен охватывать очень далеко назад в хронологическом порядке.

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

Я думаю, что использование Redis было бы более подходящим. У вас может быть список для ленты активности каждого пользователя. LPUSH user_id 'Джон только что добавил ‹a href="/johnsvideo">видео‹/a>`

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

person Trent Earl    schedule 24.12.2012
comment
Вы предлагаете денормализацию. Здесь действуют обычные предупреждения. - person usr; 25.12.2012