user1 сможет видеть что в /home/www/site2.com? Т.е. он например загрузит какой-то просмотрщик файлов на пхп и будет лазить по ввсем директориям от имени www-data, поскольку php-файлы запускаются апачем. Такое возможно?
Мой комментарий, наверное, звучит двузначно… То, что вы написали — нужно при диспетчеризации, т.е. когда открываю урл news.mydomain.com/last-news-6789.html в браузере, то будут вызваны соответствующие модуль, контроллер, экшн, но мне нужно другое… Когда уже прошла диспетчеризация, запущен соответствующий контроллер, то в нем можно вызвать примерно следующее:
$url = 'http://news.mydomain.com/last-news-6789.html';
$request = new Zend_Controller_Request_Http($url);
$params = $router->route($request);
где в $params как раз и будут нужные мне модуль, контроллер, экшн и другие параметры…
Меня именно производительность и интересует. Потому множество джойнов не подходит. Я смотрю в сторону вытаскивания данных из таблиц по их id — таких запросов будет намного больше, чем просто использовать джойны, но такие запросы будут очень быстрыми и рост БД не особо повлияет на производительность. Мне так или иначе придется кэшировать данные. Я точно знаю, что предложенный Вами способ легко выдержит выборку по 1.5М записей, думаю при возростании количества строк такой таблицы ничего особо не изменится. О подобной структуре БД писал владелец соцсети. Он писал, что при 15М записей в таблице все работает отлично. Через некоторое время он сделал апдейт ответа и написал, что теперь у него 60М записей и все работает без изменений. Это я все к тому, что понимаю все плюсы предложенного Вами варианта.
Я имел ввиду, что поле wall_record_content — это уже, по сути, кэш более сложного запроса, т.е. если отказаться от этого поля, то придется использовать дополнительные таблицы (т.е. wall_element), как я написал в вопросе. Вы все правильно пишете, я сам рассматривал такой вариант (читал на стэковерфлов о таком способе, хотя там писали о «social activity stream», где не нужно было группировать фото в одну запись, но тем не менее информация там была полезной для проектирования именно стены) с использователем поля, которое местило бы в json всю необходимую информацию. Но хотел бы еще понять как все реализовать, если держать эти json-данные как записи в других таблицах, т.е. таким способом, каким я предположил буду использовать, хотя так будет более высокая нагрузка на мускуль.
Да, сргласен на счет поля «deleted» — использую его в некотрых своих таблицах.
На счет «кеширования»: а если все же попробовать обойтись без поля «wall_record_content» и тянуть контент из теблиц (т.е. из таблицы фото, видео)? То какой алгоритм Вы бы предложили?
Да, этот подход имеет право на жизнь! Здесь, конечно, есть много минусов, но вполне подходит для решения моего вопроса!
Спасибо! А как бы Вы сделали, если бы стояло условие не кешировать прикреепленные елементы к записи на стене полем wall_record_content? Здесь минус в том, что сложно будет отследить удаленные записи из базы данных, а кешировать я могу в файлах, к примеру, — это на первое время…
Можно, конечно, проверять, существует ли фото в БД или удалено…
Наступает моммент, что при кривых запросах гуглбот создает «ддос» атаку и тогда сервер просто ложиться… и ты бросаешь все свои дела, чтобы переписать запросы и на будущее получаешь хороший урок.
На счет джойнов согласен, есть в них и плюс. Не боюсь их, а просто «некрасиво» с точки зрения проектирования системы, так как в данном случае модель стены должна быть вкурсе о том, какие типы контента в системе. Ну вот, мы и подошли к той черте, где Вы сами уже понимаете, что Ваш предыдущий ответ «сджойните все» не будет полным, поскольку останется еще много подводных камней.
>Если вы не делаете джоины, вы знаете только список записей на стене и должны сделать на каждую запись столько запросов, сколько у вас типов контента. Если 10 — то 10 запросов.
Да, согласен! Но так или иначе запросы придется все равно задавать, чтобы дополнительно вытянуть те 10 фото, те 3 опроса, те 5 видео, которые лежат в записи на стене. Вот потому я и ищу лучший путь решения…
>Вам слово не нравится? :-)
Нет, слова в порядке))
Я о том, что если я все равно буду делать по запросу к каждой записи на стену, то есть ли смысл делать множество джойнов к разным таблицам в первом запросе? Хотя я могу ошибаться, может я что-то упускаю…
Согласно запросу я 10 фото не вытяну, а просто буду знать, что к записи прикреплены какие-то фото и сообщу об этом куда нужно, после чего одним запросом я вытащу те фото, которые прикреплены к записи на стену, правильно? И еще не понял почему группировка по «w.description»?
>Посмотрите пару открытых движков соц-сетей, если вы не доверяете студентам.
На изучение чужого кода уйдет слишком много времени, а на счет структуры БД после долгих «исследований» я пришел к выводу, что именно эта структура позволить реализовать соц-функционал… Здесь нету никакой дискриминации. Если программист с 10-летним опытом даст мне совет и я буду уверен, что это плохой совет — я им не воспользуюсь и наоборот, если студент даст отличны совет — то было бы глупо им не воспользоваться.
>И вы еще после этого кого-то упрекаете в отсутствии опыта?
Не было никакого упрека… Только констатация факта… Когда я провожу собеседование с программистом, я могу довольно легко определить уровень его опыта по его ответам и вопросам… Это не высокомерие… Хотел сэкономить себе время, чтобы не объяснять больше чем нужно… И нет пределу совершенствованию… И когда придет время — займусь рефакторингом той функции :)