@Showvars Существует приличное количество ресурсов-каталогов музыки с вещанием аналогичных Вашему, но абсолютно бесплатных. Взять хотя бы Простоплеер (pleer.com) или Музебра (muzebra.com). Как Вы заставите пользователей платить?
В общем читал, что HAVING сортирует только столбцы, указанные в нем, а остальные выводит в том порядке, в котором они расположены в БД. Так и не понял, баг это, или фича. Скорее всего баг)
Решил вывести нужные мне id сообщений одним запросом, а вторым запросом получать нужные данные по этим id в IN(). На страницу выводится 15 адресатов, так что 15 id в IN() - это не так критично...
В любом случае всем спасибо!
Спасибо. Но чтобы не было такой путаницы, я называю колонки `user_from` и `user_to`.
К сожалению, так выводит наоборот только самое старое сообщение от каждого юзера. Что с HAVING что без, кстати.
@Tyranron возможно, но вроде бы на одном сервере распределить все намного легче, чем на нескольких. То есть типа запрос будет иметь вид типа
SELECT `table1`.`id.`, `table2`.name`... (если я правильно понял суть). Реализовывал такое в проекте на будущее. Намучился вообще... Пол движка переписал, а все-равно все как-то все это гротескно и брутально. Да и постоянно что-то шло как-то не так... Заморозил эту идею пока, время покажет....
@Tyranron
1) Хм, почитал про мемкэш на Хабре, пощупал - а что, отличная вещь, как оказалось! Пожалуй, добавлю его в мою обвертку для БД... По сравнению с файлами - просто день и ночь! Век живи - век учись ;)
2) Решил поддать жару и добавил в таблицу 10 000 друзей (к слову, это максимально возможное количество друзей для одного юзера на некоем популярном ресурсе Паши Недурова). Что самое интересное - запрос с таким IN выполнился медленнее не более чем на пару тысячных секунды, разница в скорости почти не заметна что при 1 000, что при 10 000 id в IN, особенно, если специально не обращать на это внимание. Чувствую, что это вин!
Кстати, мне кажется, что запрос на выборку 10 000 строк вида SELECT `id` FROM `friends` WHERE `user_id` = "1" выполняется невероятно быстро! Около 0,06 сек. Или я что-то недопонимаю?) А что будет при высоких нагрузках?
3) Хм, да, и правда, при 10 000 строках уже ощущаются заметные тормоза (на 2 секунды дольше). Это уже очень некультурно!))) Поэтому и правда, сунул в IN массив на php. Кстати, конструкция вида
$ids .= $row['id'].',';
$ids = trim ($ids, ',');
при 10 000 значений тратит на целых 2 Мб ОЗУ меньше, чем
$ids[] = $row['id'];
$ids = implode (',', $ids);
Считаю, что это полезная информация...
Еще раз покорнейше благодарю! ;)
Вау!) Это... интересно!) По-моему ларчик, хоть фомкой и с размаху, но постепенно откроется :)
Честно сказать, всегда считал, что две и более таблиц можно только джойнить, а о таком решении я даже не подумал!) Юзеров и друзей с комментами я сджойнил успешно, но после того, как весь запрос постепенно стал размером с целую страницу, я понял, что как-то это все нездорОво!)
Тогда возникает еще пара вопросов:
1) У меня кеширование осуществляется просто текстовыми файлами. Будет ли целесообразно иметь для каждого пользователя один файл (вдруг я не сплю ночами, так как мне не дают покоя лавры Паши Дурова, и мне кажется, что в моей сети будут тысячи пользователей))) )? Как-то memcached просто не хочется пока вводить...
2) Если у юзера будет несколько тысяч друзей, например. Не слишком-ли жесткое будет количество id в IN в запросе?
3) Можно ли получить все id и сразу их добавить в запрос мускулом напрямую (что-то типа WHERE `user_id` IN (SELECT `id` FROM...)) или только средствами php?
И большое спасибо за идею, реально, это, пожалуй, то, что нужно!)
@jarvis Ого!) Пользуешься принципом "Главное - что работает!" :)
В принципе да, решение достаточно простое в реализации и в работе, но боюсь представить, что будет на нагруженной системе через год. Потребуется судорожное партицирование или даже шардинг, что экономически будет совершенно не выгодно (доход от этой соц. сети не покроет стоимость оборудования, которая будет уверенно расти).
