В начале недавнего вебинара, на котором мы решали разные бизнес-кейсы с помощью SQL, я спросил у участников, кто как оценивает свой уровень владения этим языком программирования по шкале от 0 до 5.
Спустя какое-то время и пару задач, поступил один занятный комментарий в чате. Не помню дословно, но коллега отметил, что посмотрев на задачи и способы их решения, он осознал, что переоценил свои навыки SQL🙂
Вспоминая это, я вернулся во времена, когда работал в крупном банке и столкнулся с одним монструозным процессом, под капотом которого было 4 SQL скрипта — каждый длинной в 1000-1500 строк.
Скрипты бегали по разным источникам, собирали данные по клиентам, агрегировали, считали, фильтровали и т.д. и т.п. И во всем этом зоопарке надо было разобраться: научиться вносить изменения так, чтобы на проде ничего не легло и отслеживать какие изменения за собой повлекут изменения двух-трех строк кода или одного порогового значения.
Я тогда тоже подумал, что, пожалуй, до этого SQL я и не знал.
Но, как говорится, «глаза боятся — руки делают». Со временем, работа с этим «монстром» превратилась в рутинную задачу 🙂
И выработался ряд советов / полезных практик для работы с большими скриптами:
1️⃣Уменьшайте размер данных на этапе построения / отладки скрипт
Не нужно писать скрипт используя сразу миллионы строк которые есть в БД. Начните с данных за один час, данных только одного клиента и т.п. В общем, сделайте так, чтобы скрипт выполнялся быстро и вы могли максимально оперативно вносить в него изменения на этапе разработки.
2️⃣Используйте временные / промежуточные таблицы
В каждой СУБД свой синтаксис для этого, так что придется погуглить, как это делается конкретно у вас :)
Если у вас большой и составной скрипт, а вам надо поработать над изменениями в определенной его части, например, в середине, то сохраните результаты первой части запроса во временную / промежуточную таблицу и уже обращайтесь при отладке к ней. Таким образом, вы сэкономите много времени.
3️⃣Сохраните результаты работы оригинального скрипта.
Перед внесением правок, сохраните эталонный результат, чтобы было потом с чем сравнивать «а что же изменилось».
4️⃣Спросите совета у коллег :)
Как-то же они до вас дорабатывали и поддерживали этот скрипт / процесс. Наверняка найдется пара лайфхаков, которые помогут вам в работе. Не бойтесь показаться некомпетентным — все знать невозможно, тем более невозможно сразу разобраться в особенностях каждого конкретного решения. Коллеги отнесутся с пониманием, а если это здоровый коллектив, то такие вопросы будут даже приветствоваться.
В процессе работы с длинными скриптами, мой скилл в SQL определенно прокачался. Поэтому не стоит бояться трудных задач — они делают вас только лучше как профессионала.
Ну и еще не совет, а скорее, добрая рекомендация — приходите к нам на поток курса «Аналитик данных». Он уже стартовал, но вы ещё успеваете присоединиться. Будем прокачивать скиллы вместе.