Comments 11
На Stepik полно целых курсов по SQL. Но там решений нет, не к чему придраться будет. )
вовремя еженочного перечёта кубов на годовалой базе по середине процесса нажать reset - пустb решают без backup
В наше время разрешалось использовать только ANSI sql
В 3.1. я бы не стал использовать подзапрос и right join. Писать rigth join - вообще плохой тон. Это решается проще и читается легче:
select c.name as contractor, sum(op.summa) as summa
from operation op
left join contractor c on c.id_contr = op.id_contr
group by c.name
order by 1 nulls lastТут англоязычных то ресурсов мало, а вы хотите на русском. На английском рекомендую аналог leetcode только для SQL: https://www.stratascratch.com/
И советую сразу учиться форматировать SQL-код, если уж вы выносите их на всеобщее обозрение - ваши запросы плохо читаются.
Большое спасибо за замечания и за ссылку на ресурс! С форматированием – исправлюсь?
Делая подзапрос на агрегацию, я исходил из того, что лучше сократить объём информации, которая джойнится. Я не прав?
И ещё, подскажите, плиз, почему rigth join – плохой тон?
Мое мнение - оптимизацией запроса нужно заниматься когда это действительно нужно. Это зависит от множества факторов таких как: конкретная СУБД, конкретные данные, модель данных, индексы, паралеллизм, оптимизатор в субд, план запроса и т.д. и т.п. А до тех пор пока такой задачи не стоит - а у нас тут нет ничего, только задачка в вакууме - нужно писать как можно проще и понятнее.
Right join - абсолютно бесполезная вещь, которая только сбивает с толку. Нет такого right join который бы нельзя было бы заменить на left join. Поэтому принято использовать left join - он более интуитивно понятен. Погуглите различные "SQL style guide" от топовых компаний, в них зачастую вообще явный запрет на использование right join.
Спасибо за статью, но при обсуждении оптимизации запросов неплохо бы еще обсуждать планы получаемых запросов. Коротко и понятно написанный запрос не всегда является оптимальным с точки зрения базы - к сожалению.
Планы где? В какой СУБД и на какой версии? На каких данных? В задачах не указано ничего кроме условия задачи. Какой может быть план?
Во-первых, автор указал, что решения он предложил для SQLite. Это как минимум нас
приземляет на какой-то диалект SQL и формат вывода планов. Тут Вы видимо не очень внимательно читали.
Ну а то, что нужна схема данных, нужны данные, нужна статистика по этим данным
это и так очевидные факты любого кто занимается анализом произаводительности запросов.
Нет ничего проще это сделать и выложить хоть на гитхабе, чтобы любой мог повторить.
И статья от этого только выиграет.
И не соглашусь с Вами... Заниматься оптизацией можно и нужно в любое время, хоть на модельных примерах,
хоть на продуктовых данных. Это полезный труд, показывающий другим существенные детали
для понимания процесса оптимизации запросов.
Я бы пожалуй упомянула sql-ex. Там есть и совсем простые и достаточно каверзные задачи. А если учесть что у них есть тестовая база с очень странным набором данных, то решения в лоб не всегда работают. Ну а если скучно просто решать задачи, то можно и посоревноваться с другими пользователями данного ресурса.
Об интересных задачах по SQL