Comments 15
повторяю вопрос, на который не совсем получил ответ в прошлый раз:
чем обусловлено желание всю работу выполнять одним запросом?
чем обусловлено желание всю работу выполнять одним запросом?
По этим запросам не могу судить, но могу рассказать про sql-ex.ru, где правила там такие — один запрос и не более 8000 знаков.
Идея этих задач — в хорошем знании sql и к тому же к нестандартному мышлению. Некоторые задачи оттуда — ну вот действительно, кажется, что невозможно решить одним запросом, а как оказывается — можно, так и еще и по производительности будут на высшем уровне. К тому же люди там находят более производительные планы выполнения.
По этим задачам могу прикинуть, что решения первой и третьей — нормальные, но вот второй — ни в коем случае не используйте в продакшене (на каждую строку Exists — это издевательство)!
Идея этих задач — в хорошем знании 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 по своей природе спортивный, а в топике человек решает жизненную задачу.
(с) третья. это нормально?
а в первой запрос был бы гораздо проще и быстрее, если бы структура была нормальной. равно как и во 2, и в 3.
ps: а вообще «нормальность» решений покажет EXPLAIN. автор, покажите EXPLAIN'ы ко всем запросам
pps: sql-ex.ru года 3 назад проходил. но sql-ex по своей природе спортивный, а в топике человек решает жизненную задачу.
у меня создатель sql-ex.ru уже второй год SQL преподает.
а вот на счет нестандартного мышления, я бы немного перефразировал — «SQL'ьное мышление».
Буквально для 3-4 назад на паре он рассказывал про существования подкласса задач, которые не решаются в один запрос. Вот это меня даже озадачило, ибо сколько последнее время запросов не писал, все получается делать в один, и без лишнего гемороя
а вот на счет нестандартного мышления, я бы немного перефразировал — «SQL'ьное мышление».
Буквально для 3-4 назад на паре он рассказывал про существования подкласса задач, которые не решаются в один запрос. Вот это меня даже озадачило, ибо сколько последнее время запросов не писал, все получается делать в один, и без лишнего гемороя
Это вопрос именно «религиозный» — кто как больше любит делать. :-) Но стоит понимать, что единого универсального способа решить задачу не существует при некоторых обстоятельствах будет лучше одно, при некоторых — уже совсем другое.
У меня желание «всю работу выполнять одним запросом» обусловлено тем, что один запрос проще оптимизировать. Проще подогнать индексы под 1 большой запрос, чем тоже самое сделать с 10-ю маленькими. Этим вобщем-то и вызвано. И еще я не согласен с тем, что всегда 10 маленьких будут выполнятся быстрее, чем один большой. Но доказать это не могу, впрочем как и вы не можете доказать обратное.
У меня желание «всю работу выполнять одним запросом» обусловлено тем, что один запрос проще оптимизировать. Проще подогнать индексы под 1 большой запрос, чем тоже самое сделать с 10-ю маленькими. Этим вобщем-то и вызвано. И еще я не согласен с тем, что всегда 10 маленьких будут выполнятся быстрее, чем один большой. Но доказать это не могу, впрочем как и вы не можете доказать обратное.
третья задача была бы элементарной, если бы в мусике были реализованы оконные функции (тогда бы не нужны были приседания с переменными)
Зачем
HAVING COUNT(i.id) > 0если JOIN и так INNER? Он какбы и так должен отсеять пустые галереи…
Ну вот, очередной вариант, когда автор не до конца рассказывает задачу, а в приведённом решении разжевывает каждое решение, основываясь только на том, подходит решение для него лично или нет, или базируясь на однозначно своём решении
Берём условие первой задачи:
И теперь самое главное не понимаем, зачем присоединять дополнительную таблицу, если уже известна c_id? (id категории)
Вторая задача:
Я нигде не заметил в данном условии, что выбрать следующую и предидущую фотографию надо ОДНОВРЕМЕННО! И самое главное непонятно, зачем делать это одним запросом (хотя условия могут быть разные).
Опять таки, в решении: если уже известна id фотографии, ЗАЧЕМ присоединять ещё дополнительно две таблицы, если можно использовать только одну с фотографиями?
Третья (последняя) меня подвергла в полное уныние, ибо я так понимаю, что все поняли как поняли задачу, соответственно и решили как поняли
То есть, если я правильно читаю условие:
1. Дано число N.
2. Вывести список категорий
3. В каждой категории надо вывести список альбомов не более N. и т.д.
Соответственно, выводить надо альбомы? или же всё-таки фотки?
Итоговые вопросы: если альбомы, зачем привязываться к фоткам, если фотки — зачем мучаться с обложкой альбома.
То есть, условие задачи поставленно абсолютно некорректно
Собственно, предложенные решения меня подвергли больше в уныние.
Хотя задачи голову на часок помогли отвлечь ;-)
Берём условие первой задачи:
Дано 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) Категории, альбомы и фотки. На один альбом одна фотка, по возможности главная, если нет — то любая другая. Итоговые вопросы я не понял вообще.
1) по флагу is_published должен исключаться сам объект и все в него входящие объекты. То есть, если на категорию is_published = 0 то все альбомы и соответственно все их фотки должны исключаться (причем уже пофигу опубликованы они или нет).
— так что тут все понятно.
2) Я нигде не заметил в данном условии, что выбрать следующую и предидущую фотографию надо ОДНОВРЕМЕННО! — все верно, я этого и не говорил. Можно было как угодно. Что я сделал — я просто 2 запроса объединил в один, хотя это по сути 2 разных запроса. Если уже известны id фотограии нужно присоединять остальные таблицы за тем, что бы выполнялось уже приведенное условие.
3) Категории, альбомы и фотки. На один альбом одна фотка, по возможности главная, если нет — то любая другая. Итоговые вопросы я не понял вообще.
То есть, если исходить из ситуации, что надо просматривать каждый раз, разрешены ли для публикации все категории, галереи и фотографии — то тогда понятно, почему приходится работать с тремя таблицами одновременно. Хотя мне не встречалось, чтобы можно было получить, допустим id категории, и при этом эта категория была недоступна… (ну это уже надо смотреть на реальные условия)
То есть, условие
должно присутствовать во всех запросах. Теперь становится более понятным задание.
Хотя, логично предположить, что условие выполнено, если id уже известно ;-)
А на третье:
Порядок того, что должно быть выведено:
Категории
В каждой категории энное количество альбомов (лимит N)
Для каждого альбома — обложка
Правильно?
Тогда непонятно — каким образом в данную конструкцию вписываются фотографии (кроме обложки), о которых собственно и идёт речь в задании :-/
То есть, условие
3) Для всех задач нельзя показывать пустые галереи и категории, то есть те категории в которых нет галерей и те галереи в которых нет категорий
должно присутствовать во всех запросах. Теперь становится более понятным задание.
Хотя, логично предположить, что условие выполнено, если id уже известно ;-)
А на третье:
Порядок того, что должно быть выведено:
Категории
В каждой категории энное количество альбомов (лимит N)
Для каждого альбома — обложка
Правильно?
Тогда непонятно — каким образом в данную конструкцию вписываются фотографии (кроме обложки), о которых собственно и идёт речь в задании :-/
Обложки может и не быть (ни одна фотография в галерее не отмечена как обложка) — но что-то нужно вывести заместо нее. Тогда надо взять любую фоту из этой галереи — первую, последнюю не важно.
Обложки может и не быть (ни одна фотография в галерее не отмечена как обложка) — но что-то нужно вывести заместо нее
Под обложкой это и подразумевалось: либо выделенная (is_main_foto), либо первая is_published.
Вопрос был собственно в другом, и я специально вставил условие задания.
Надо вывести альбомы для категорий с лимитом? Почему тогда в условии речь зашла про фотографии, если нигде кроме как «обложка» они не фигурируют?
Sign up to leave a comment.
Три интересные задачи на знание SQL — Решения