jarvis

c++ производительность повысит(хотя не факт, если криво напишут, то еще хуже будет) но вам это сейчас не требуется, только время и деньги на доработку потеряете.

Когда у вашего интернет магазина будет 5000 запросов в секунду(а это примерно 0.5-1 млн пользователей в час, это нагрузка уровня Озона), то во-первых, это будет приятно, а во-вторых у вас уже будут ресурсы чтобы нанять профессионалов и грамотно отмасшабироваться.

Обычно самое узкое место - это обращения к БД. Используйте грамотное кэширование и оптимизацию запросов к БД.

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

Из таблиц не надо тянуть для всей стены, слишком тяжело.
На счет «кэширования»? А в чем проблема закэшировать ответ на мой запрос? Тот же memcashed отлично закэширует результаты запросы

Select  * from wall_1234 where owner_id=Owner_id_from_request Limit 0, 20

Ладно, давайте я объясню механизм подробнее. В поле «wall_record_content» вся фишка. Оно нам крайне необходимо и именно оно позволяет нам очень легко выводить данные. Но для этого нам придется заплатить тем, что вводить их будет немного сложнее. Но это не страшно, в соц сети намного чаще читают чем пишут.

Начинаем.
Пользователь создает пост на стене друга.

Готовим запрос на сервер. Вначале кипятим воду включаем личные данные пользователя как автора(имя и id в приложении) и id друга для поля id_owner_user в запрос. Отлично, мы молодцы, но это еще не все.

Дальше пользователь вводит описание. Ничего себе. Тоже вставляем эти данные в параметр description нашего запроса. Идем дальше.
Пользователь прикрепляет фото и видео. Чтобы можно было просматривать фото нам необходим адрес маленькой картинки(в дальнейшем буду называть его «превьюшкой» )и адрес страницы, где мы будем просматривать фото в полном размере. Допустим у нас есть несколько способ прикрепления фото: драг-эн-дропом, если фото уже было добавлено на сервер, или сразу с локального компьютера(или телефона)

Если фото было ранее загружено на сервер (то есть эти данные уже записаны в БД), то просто с помощью ajax запроса получаем эти данные из БД.(Возможно и не потребуется, если на страницк у нас уже есть необходимые данные для фото). Полученные данные вставляем в параметр массив Post_images.

Если нет, то ПЕРВЫМ ДЕЛОМ ЗАГРУЖАЕМ ФОТО НА СЕРВЕР с помощью ajax запроса(с помощью него будет проще) и вносим данные о фото в таблицу images. Когда это будет сделано, возвращаем данные ajax запросом. Включаем их в параметр Post_images. Неплохо.

Теперь у нас есть параметр в котором содержатся данные о фотографиях, которые прикреплены к посту.

Аналогично с видео и аудио. Супер!

Теперь у нас есть полностью сформированные Post запрос с параметрами author_user_id, author_user_name, owner_id, post_description, Post_images, Post_videos. Отправляем на сервер. И не забываем про CSRF-защиту. Мы любим своих пользователей и заботимся о них.

На сервере принимаем данные запрос, обрабатываем его и записываем в БД как я писал в первом посте.
Пример json-a, которые попадет в БД.

content: {
description: Срочно оцени эти супер-крутые фотки! ,
Mysuper_Puper_Images: [{
Photo_link1{
preview:"images.site.com/dsfgdfgsdg.jpg"
link:"www.site.com/viewphoto/345345345345"
},
Photo_link2{
preview:"images.site.com/dsfgdfgsdg.jpg"
link:"www.site.com/viewphoto/345345345345"
}

}],
Mysuper_Puper_Video_links[{
videolink1{}, videolink2{}
}]
и т.д,
}

Вот и все, теперь у нас в базе лежит пост пользователя.

В сеть выходит друг Павел Недуров. Первым делом он идет на свою стену, чтобы просмотреть, что симпатичные девчонки написали ему за день. При загрузке его стены мы формируем запрос

Select  * from wall_1234 where owner_id=Owner_Павел НедуровID Limit 0, 20

Наш скрипт получает из базы( или memcashed) результат выполнения этого запроса. Обрабатываем эти данные и выводим их в нашем шаблоне, не забывая все экранировать для предотвращения xss атак. Мы любим пользователей!

В итоге на странице будет выведено:
1)текст записи
2)маленькие картинки, по клику на превьюшку переходим на страницу, где можно просмотреть большую версию.
3)маленькие картинки с кадром из видео, по клику переходим на страницу, где можно просмотреть видео(хм, где-то я уже это слышал)

Пост друга Павлу понравился! Но вот незадача, симпатичные девчонки сегодня ничего не написали. Не горюй, бро, твое время еще придет. А на этом наша программа подходит к концу. В следующей передаче раз мы будем делать новостную ленту. Оставайтесь на связи.

В итоге благодаря моему способу очень легко и быстро выводить записи, ведь все данные мы получаем одним запросом. И легко кэшировать. И индексы тоже можно использовать. Картинки хранятся в таблице images, видео — в videos. Все можно легко просмотреть. Но с реализацией ввода поста придется немного попотеть, но результат того стоит.

P. S. Не принимайте ничего на свой счет, это у меня просто такой стиль.

Я бы сделал так:(читать до конца)
1)создал бы таблицу wall с полями id, author_user_id, author_user_name, owner_user_id, wall_content, где
-id идентификатор записи в таблице-
— author_user_id — идентификатор пользователя создавшего пост
-author_user_name его имя, внесем сюда же, чтобы не делать лишний запрос к таблицам пользователей
-owner_user_id — идентификатор владелец стены
-wall_record_content — контент записи. представляет собой json с полями title, description,images, видео, опросы и что у ваc там есть. пример

content: {
title: SuperProPost,
Mysuper_Puper_Images: [{
Photo_link1, Photo_link1

}],
Mysuper_Puper_Video_links[{
videolink1, videolink2....
}]
и т.д,
}

Структура на самом деле будет немного посложней, но я думаю вы справитесь.
И потом уже в самом скрипте обрабатывать этот json и формировать шаблон. При записи и изменении скриптом формировать этот json и записывать его в БД,

В итоге все будет получено одним запросом, нагрузка на БД будет минимальна. Без джойнов.

Select  * from wall_1234(лучше использовать шардинг чтобы не было по 20 млн записей в одной таблице) where owner_id=Owner_id_from request Limit 0, 20 (к примеру)

На каждые 50 пользователей выделять отдельную таблицу wall_groupId. Таким образом все данные для стены будут получены, внимание, в ОДИН запрос из таблицы на 100-300 тысяч записей, за что БД скажет нам спасибо
Я надеюсь мысль ясна, подкорректируйте под свои нужды.