Pull to refresh

Comments 15

повторяю вопрос, на который не совсем получил ответ в прошлый раз:
чем обусловлено желание всю работу выполнять одним запросом?
По этим запросам не могу судить, но могу рассказать про sql-ex.ru, где правила там такие — один запрос и не более 8000 знаков.
Идея этих задач — в хорошем знании sql и к тому же к нестандартному мышлению. Некоторые задачи оттуда — ну вот действительно, кажется, что невозможно решить одним запросом, а как оказывается — можно, так и еще и по производительности будут на высшем уровне. К тому же люди там находят более производительные планы выполнения.
По этим задачам могу прикинуть, что решения первой и третьей — нормальные, но вот второй — ни в коем случае не используйте в продакшене (на каждую строку Exists — это издевательство)!
WHERE IF (@cid=q.cid, @a:=@a+1, (@cid:=q.cid) AND (@a:=1)) <= N;
(с) третья. это нормально?

а в первой запрос был бы гораздо проще и быстрее, если бы структура была нормальной. равно как и во 2, и в 3.

ps: а вообще «нормальность» решений покажет EXPLAIN. автор, покажите EXPLAIN'ы ко всем запросам

pps: sql-ex.ru года 3 назад проходил. но sql-ex по своей природе спортивный, а в топике человек решает жизненную задачу.
Могу привести, да. Только я не понимаю, что это даст. Эксплейн эффективен, только если сравнивать с чем либо, а тут с чем сравнивать?
у меня создатель sql-ex.ru уже второй год SQL преподает.
а вот на счет нестандартного мышления, я бы немного перефразировал — «SQL'ьное мышление».
Буквально для 3-4 назад на паре он рассказывал про существования подкласса задач, которые не решаются в один запрос. Вот это меня даже озадачило, ибо сколько последнее время запросов не писал, все получается делать в один, и без лишнего гемороя
Это вопрос именно «религиозный» — кто как больше любит делать. :-) Но стоит понимать, что единого универсального способа решить задачу не существует при некоторых обстоятельствах будет лучше одно, при некоторых — уже совсем другое.

У меня желание «всю работу выполнять одним запросом» обусловлено тем, что один запрос проще оптимизировать. Проще подогнать индексы под 1 большой запрос, чем тоже самое сделать с 10-ю маленькими. Этим вобщем-то и вызвано. И еще я не согласен с тем, что всегда 10 маленьких будут выполнятся быстрее, чем один большой. Но доказать это не могу, впрочем как и вы не можете доказать обратное.
третья задача была бы элементарной, если бы в мусике были реализованы оконные функции (тогда бы не нужны были приседания с переменными)
Зачем
HAVING COUNT(i.id) > 0
если JOIN и так INNER? Он какбы и так должен отсеять пустые галереи…
Да, согласен. Это просто для «полноты», на самом деле это не нужно. У меня изначально стояли LEFT JOIN (так было нужно) в последний момент я их исправил на JOIN так как LEFT тут нафиг сдался, а про условия как-то не подумал.
Ну вот, очередной вариант, когда автор не до конца рассказывает задачу, а в приведённом решении разжевывает каждое решение, основываясь только на том, подходит решение для него лично или нет, или базируясь на однозначно своём решении

Берём условие первой задачи:
Дано ID категории. Нужно написать запрос (один!) который бы получал все галереи этой категории, для каждой из которых получал ID главной фотографии, а если таковой нет — то ID какой-нибудь входящей в категорию (все равно, лишь бы была фота)

И теперь самое главное не понимаем, зачем присоединять дополнительную таблицу, если уже известна c_id? (id категории)

Вторая задача:
Дано ID фоты. Если хотите — так же ID галереи. Требуется с минимум усилий определить следующую/предидущую фоту в порядке по ordi. (напоминаю, что тут только по ordi принимать решение нельзя так как следующая/предидущая может быть и is_published = 0, таким образом надо взять ближайшую которая is_published = 1). Задача решается 2-мя запросами, я уверен что можно решить и одним (без UNION) но у меня не получилось. Если у кого получится тому респект и уважуха. :-)

Я нигде не заметил в данном условии, что выбрать следующую и предидущую фотографию надо ОДНОВРЕМЕННО! И самое главное непонятно, зачем делать это одним запросом (хотя условия могут быть разные).
Опять таки, в решении: если уже известна id фотографии, ЗАЧЕМ присоединять ещё дополнительно две таблицы, если можно использовать только одну с фотографиями?

Третья (последняя) меня подвергла в полное уныние, ибо я так понимаю, что все поняли как поняли задачу, соответственно и решили как поняли
Это самая жесть. Дано некоторое число N. Требуется вывести список категорий, и количество последних альбомов в них, причем для каждой категории это количество не должно быть больше N и отсортировано в порядке убывания по ordi. То есть допустим 3 категории, в 1-ой 10 фоток, во второй 25, а в третей только три. Нужно чтоб на выходе было для первой 5 последних (с наибольшими ordi отсортированных по убыванию), для второй 5 (аналогично) и для 3-ей — 3 (аналогично). Плюс условие первой задачи, то есть надо еще главную фоту для галереи или какую-нибудь еще

То есть, если я правильно читаю условие:
1. Дано число N.
2. Вывести список категорий
3. В каждой категории надо вывести список альбомов не более N. и т.д.
Соответственно, выводить надо альбомы? или же всё-таки фотки?
Итоговые вопросы: если альбомы, зачем привязываться к фоткам, если фотки — зачем мучаться с обложкой альбома.
То есть, условие задачи поставленно абсолютно некорректно

Собственно, предложенные решения меня подвергли больше в уныние.
Хотя задачи голову на часок помогли отвлечь ;-)
1) Ну да, у нас есть ID категории. Но данная категоря может быть и не опубликована, в этом случае результат должен быть нулевым.

1) по флагу is_published должен исключаться сам объект и все в него входящие объекты. То есть, если на категорию is_published = 0 то все альбомы и соответственно все их фотки должны исключаться (причем уже пофигу опубликованы они или нет).

— так что тут все понятно.

2) Я нигде не заметил в данном условии, что выбрать следующую и предидущую фотографию надо ОДНОВРЕМЕННО! — все верно, я этого и не говорил. Можно было как угодно. Что я сделал — я просто 2 запроса объединил в один, хотя это по сути 2 разных запроса. Если уже известны id фотограии нужно присоединять остальные таблицы за тем, что бы выполнялось уже приведенное условие.

3) Категории, альбомы и фотки. На один альбом одна фотка, по возможности главная, если нет — то любая другая. Итоговые вопросы я не понял вообще.
То есть, если исходить из ситуации, что надо просматривать каждый раз, разрешены ли для публикации все категории, галереи и фотографии — то тогда понятно, почему приходится работать с тремя таблицами одновременно. Хотя мне не встречалось, чтобы можно было получить, допустим id категории, и при этом эта категория была недоступна… (ну это уже надо смотреть на реальные условия)

То есть, условие
3) Для всех задач нельзя показывать пустые галереи и категории, то есть те категории в которых нет галерей и те галереи в которых нет категорий

должно присутствовать во всех запросах. Теперь становится более понятным задание.
Хотя, логично предположить, что условие выполнено, если id уже известно ;-)

А на третье:
Порядок того, что должно быть выведено:
Категории
В каждой категории энное количество альбомов (лимит N)
Для каждого альбома — обложка
Правильно?
Тогда непонятно — каким образом в данную конструкцию вписываются фотографии (кроме обложки), о которых собственно и идёт речь в задании :-/
Обложки может и не быть (ни одна фотография в галерее не отмечена как обложка) — но что-то нужно вывести заместо нее. Тогда надо взять любую фоту из этой галереи — первую, последнюю не важно.
Обложки может и не быть (ни одна фотография в галерее не отмечена как обложка) — но что-то нужно вывести заместо нее

Под обложкой это и подразумевалось: либо выделенная (is_main_foto), либо первая is_published.

Вопрос был собственно в другом, и я специально вставил условие задания.
Надо вывести альбомы для категорий с лимитом? Почему тогда в условии речь зашла про фотографии, если нигде кроме как «обложка» они не фигурируют?
Only those users with full accounts are able to leave comments. Log in, please.