-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Нужна помощь по созданию sql запроса
- Автор темы VL-ad
- Дата начала
VL-ad
Новичок
Вурдалак, в принципе тоже вариант, скорее всего так и сделаю - если ничего лучше не получится.
Chusha,
Не понял, как его обработать на php, стандартно через while не получается, если можешь дай пример.
Вообще глянул через vardump он получает список постов и по 1му комменту, берёт последнее поле из таблицы comments
Chusha,
PHP:
0.0061559677124023Вообще глянул через vardump он получает список постов и по 1му комменту, берёт последнее поле из таблицы comments
PHP:
array(2) {
["g"]=>
string(23) "438,447,450,451,452,456"
["NULL"]=>
NULL
}
array(2) {
["g"]=>
string(1) "1"
["NULL"]=>
string(19) ".... какое то ))"
}
array(2) {
["g"]=>
string(1) "2"
["NULL"]=>
string(5) "ага))"
}
array(2) {
["g"]=>
string(1) "2"
["NULL"]=>
string(14) "чики нормуль))"
}
array(2) {
["g"]=>
string(1) "2"
["NULL"]=>
string(30) "Сделайте пожалуйста"
}
array(2) {
["g"]=>
string(1) "3"
["NULL"]=>
string(28) "Даёшь крушение системы!!!)))"
}Mols
Новичок
VL-ad
ИМХО, в Вашем случае надо сделать поле last_comment_time_marker в таблице с комментируемыми данными.
При добавлении коммента обновлять это поле.
А выбирать просто тупо.
Одним запросом 15 записей из первой таблицы и 15 запросов к таблице с комментариями (каждая для получения 3х комментов к материалу из первой таблицы ).
А все эти "решения", что тут понаписали - забудьте как страшный сон.
Читабельности они не добавят. Простоты поддержки тоже. В общем никаких реальных плюсов Вы не получите.
ИМХО, в Вашем случае надо сделать поле last_comment_time_marker в таблице с комментируемыми данными.
При добавлении коммента обновлять это поле.
А выбирать просто тупо.
Одним запросом 15 записей из первой таблицы и 15 запросов к таблице с комментариями (каждая для получения 3х комментов к материалу из первой таблицы ).
А все эти "решения", что тут понаписали - забудьте как страшный сон.
Читабельности они не добавят. Простоты поддержки тоже. В общем никаких реальных плюсов Вы не получите.
Mols
Новичок
Вурдалак
1. не N+1 а конкретно 16
2. не просто "запросов", а селектов по вполне селективным индексам
3. не нравится не ешьте))) Это моё мнение и мой личный практический опыт. Работает очень быстро, читается удобно и кеш никто не отменял.
[update]
хотя до кеша тут врядли дойдет.
Вот например конкретные цифры на реальной базе и дешёвом хостинге.
Первый вход
Кеш не используется ибо мощности вполне хватает.
Куча простых запросов. Все по нормальным индексам. Всё легко читается и расширяется. По мере надобности вносятся оптимизации....
А не 3 дня мусолится то, что надо сделать за 20 минут и забыть лет на 5.
1. не N+1 а конкретно 16
2. не просто "запросов", а селектов по вполне селективным индексам
3. не нравится не ешьте))) Это моё мнение и мой личный практический опыт. Работает очень быстро, читается удобно и кеш никто не отменял.
[update]
хотя до кеша тут врядли дойдет.
Вот например конкретные цифры на реальной базе и дешёвом хостинге.
Первый вход
Сразу повторныйКол-во запросов к базе: 107 Время выполнения: 0.121556997299 сек
Пользователь авторизован. Примерно половина запросов уникальна для каждого пользователя.Кол-во запросов к базе: 104 Время выполнения: 0.0474660396576 сек
Кеш не используется ибо мощности вполне хватает.
Куча простых запросов. Все по нормальным индексам. Всё легко читается и расширяется. По мере надобности вносятся оптимизации....
А не 3 дня мусолится то, что надо сделать за 20 минут и забыть лет на 5.
Mols
Новичок
Chusha
ну зачем категоричный то?.... я ж сразу написал ИМХО... да и наблюдал я долго за этими трепыханиями))) Мальца не выдержал.
Тут наверное будет тот же случай, что и с большинством. Стремление "все сделать одним запросом" у ТС пройдет только со временем.
У меня так было.
Про цифры конечно Вы правы. Я не буду здесь приводить описание базы и количества записей ОК?
Кому оно надо? В архиве дамп 200 метров (да да знаю разные опции архивирования и т.п и т.д...). Не сильно много но и не мало.
А решение я ТСу предлагаю по типу "сделать максимально просто" и иметь возможность мониторить производительность.
Другими словами оптимизировать тогда, когда будет надо.
Чем раньше он это поймет, тем больше сил сэкономит)))
З.Ы.
Не смею больше вмешиваться.
ну зачем категоричный то?.... я ж сразу написал ИМХО... да и наблюдал я долго за этими трепыханиями))) Мальца не выдержал.
Тут наверное будет тот же случай, что и с большинством. Стремление "все сделать одним запросом" у ТС пройдет только со временем.
У меня так было.
Про цифры конечно Вы правы. Я не буду здесь приводить описание базы и количества записей ОК?
Кому оно надо? В архиве дамп 200 метров (да да знаю разные опции архивирования и т.п и т.д...). Не сильно много но и не мало.
А решение я ТСу предлагаю по типу "сделать максимально просто" и иметь возможность мониторить производительность.
Другими словами оптимизировать тогда, когда будет надо.
Чем раньше он это поймет, тем больше сил сэкономит)))
З.Ы.
Не смею больше вмешиваться.
Вурдалак
Продвинутый новичок
N — количество новостей на странице, если кто не понял.не N+1 а конкретно 16
Ты вообще понял моё предложение?
Mols
Новичок
Да понятно, что Вы имели в виду под N.
просто оно четко определено для этой задачи.... это если кто не понял.
Думаю Ваше предложение сводилось к выборке 15 записей, потом пробежаться по ним и собрать строку для IN(....) и применить этот IN для комментов.
Так что решите сами... понял я или нет. Может был какой-то другой, тайный смысл?
1. Вы упустили из виду требование о том, что нужны только те строки к которым комментарии добавлены в течение последней недели (ну или делать джойн с MAX по дате коммента)
2. да, мне не нравится этот вариант и моё ИМХО - так делать не надо. Плюсов (опять же на мой взгляд) в этом нет. Несмотря на N+1 (и любые другие алгебраические записи).