Эффективность дизайна базы данных ленты новостей - PullRequest
3 голосов
/ 12 января 2010

Привет всем, я видел похожие вопросы, которые задавались ранее, без убедительных или проверенных ответов.

Я разрабатываю систему новостной ленты, используя PHP / MySQL, похожую на Facebook. Учитывая, что эта таблица может вырасти до довольно большой - любая неэффективность может привести к значительному узкому месту.

Пример уведомлений: (Элементы, выделенные жирным шрифтом, являются связанными объектами)

User_A и USER_B прокомментировал User_C's новый альбом .

Пользователь_A добавил новый Автомобиль в [его / ее] гараж.

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

Это работает, но я боюсь, что это недостаточно масштабируемо, теперь я смотрю на сериализацию объектов.

Так, например, моя новая база данных настроена так:

News_ID  |  User_ID  |                 News_Desc            |   Timestamp

  2643         904     {User904} and {User890} commented on     SomeTimestamp
                       {User222}'s new {Album724}.

Все, что внутри {представляет данные, которые будут сериализованы с использованием JSON.

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

Будет ли трудно отделить сериализованные данные от остальной части строки с помощью регулярных выражений?

1 Ответ

2 голосов
/ 12 января 2010

Что произойдет, если пользователь 890 удалит свой комментарий? Я думаю, вам нужно быть более атомарным - возможно, сохраняя тип действия (комментарий) с помощью actioner (User890), а затем генерируйте реальную историю на лету с интенсивным кэшированием. Это также поможет решить проблему перевода, если вы расширите свой сайт на несколько рынков / аудиторий.

...