balloon

Мы делали опираясь на второй вариант, при этом id друзей кэшировали (т.е. в итоге был простой запрос вида select * from feed where author_id in (1,2,3). И всё было просто до следующих требований:
1. Нужно было выводить только те записи друга, которые создали после добавления друга (от этого в последствии отказались из-за чрезмерного оверхеда и сомнительной выгоды)
2. Если кто то из твоих друзей откомментил пост — то он должен был поднятся наверх (упростли до требования поднимать вверх сообщение если хоть кто то его откомментил. Как результат просто ввели еще одно поле с датой апдейта и сортировали по нему)
3. Приватность для записей, которые ссылаются на другую запись. Вроде Твой дружище лайкнул пост своего друга, который не твой друг. В этом случае если оригинальный пост доступен только для друзей(а вы с ним не друзья), то его не нужно было показывать. (В данном случае автором оставлася всегда оригинальный автор, а сообщение помечалось как ссылка и юзера, который его ретвитил мы записывали в отдельное поле).

Были и специфичные требования:
1. Юзера можно было поставить игнор на N дней. В течении этого времени его сообщения должны были игнорирваться.
2. Пост можно было пометить как избранный, и он постоянно висел в топе (нужно было для мониторинга)

P.S. кстати в первом варианте выгоднее создать 2 таблицы. Одна — с сообщениями. Вторая EventId,UserId.

Внесу и свою лепту. Я бы:
1. Отказался от сокращенного найменования полей и назвал бы некоторые поля по другому bid -> blog_id, uid -> user_id, uid_add -> created_by, uid_upd -> updated_by, time_add -> created_at, url_name -> slug
2. Объединил таблицы post, special, special_page, news (и соотв. вместо 2 таблиц news_tag & post_tag осталась бы одна) + как уже упомянули, решился бы вопрос с комментариями
3. Для статуса использовал бы ENUM вместо INT(1), а если ENUM нельзя — то хотя бы TINYINT :)
4. Если комментариев много — то использовал бы nested set либо добавил поле с путем для быстрого вывода дерева (в чем поле level не помогает вроде)