Я всегда составляю для себя Типовые запросы - список готовых запросов, которые можно потом скопировать, а не писать заново. Тут есть основные показатели, чтобы не путаться, как правильно их считать. Здесь же и редкие вещи, расположение которых легко забыть и трудно найти заново. А еще полезные функции, например, как получить инфу о таблице или вытащить айдишку товара из урла. В общем, этим файлом я пользуюсь постоянно.
Однажды я стала раздавать его всем желающим. Потом я ушла из компании в декрет, но вернувшись через два года обнаружили, что дело моё живёт. Я была представлена как человек, создавший Типовые запросы, и встречена громкими криками одобрения. Мне было очень приятно.
Но не все одобряют такой подход. Ниже я решила собрать все плюсы и минусы раздачи всем подряд Типовых запросов. Лично я считаю такую практику полезной, поэтому начну с плюсов:
Быстрый вход для новичков. Один файл - и вот ты уже можешь посчитать основные метрики.
Меньше вопросов типа «а как посчитать/а где лежит». Экономит время всех членов команды. Особенно актуально, если нет хорошего описания базы данных (то есть практически всегда).
Единая методика подсчета ключевых метрик - все копируют формулу, а не изобретают ее заново.
Единообразие кода - новички перенимают представленный в Типовых запросах стиль.
А теперь посмотрим на минусы:
Меньше понимания устройства базы, потому что можно скопировать, не думая
Команды хуже запоминаются - например, команда с получением инфы о таблице состоит из двух слов, но я ее за полгода так и не запомнила, потому что зачем, если можно скопировать, не глядя.
Копирование ошибки, если ошибка есть в Типовых запросах
Непонятно, кто должен вести этот список и держать его в актуальном состоянии.
Есть ещё один момент - где вести документ? Мне удобней всего было иметь именно файл sql. Сохраняется разметка, всегда под рукой, некоторые вещи можно запустить прям в нем, легко редактировать. Для организации общего доступа этот файл лежал в общей папке. На новом месте работы общих папок не было, и типовые запросы попробовали организовали в confluence. Мне показался такой метод менее удобным, в первую очередь из-за трудностей редактирования. Зато доступ легче и делиться с другими проще. Плюс никто не создаст себе локальную копию файла и не останется потом без актуальных обновлений.
Теперь у меня другая забота - как организовать Типовые запросы при наличии нескольких баз данных. Если группировать их по базам, то сложно найти нужный скрипт. Если группировать по смыслу, то путаница происходит с базами. Второй подход пока мне нравится больше, просто приходится перед скриптом указывать имя базы. Но посмотрим, как пойдёт дальше.
А у вас есть Типовые запросы? Где вы их ведёте? Кто следит за актуальностью?
UPD
Речь про отдел аналитики, где люди активно работают с базой данных и 80% своего времени пишут SQL-код. Как правильно указали в комментарии, отделу HR не нужно знать базу
Комментарии (10)
itille
21.04.2022 10:27Есть, храню в обычных текстовых файлах, разбитых по базам данных и тематике. Типовые запросы, а особенно краткие описания UDF. Очень полезно в случае, когда из нескольких баз, у каждой и которых есть свой хозяин, необходимо получить сводный отчет, не вдаваясь в структуру базы.
Плюс отдельные файлы с интересными редко используемыми скриптами из разных источников и различными реализациями стандартных запросов, скорость которых может сильно зависеть от состава данных. ( Для примера, на разных наборах данных время получения последних значений подчиненной таблицы сильно зависит от типа запроса, и сразу не скажешь, какой подойдет лучше в конкретном случае, а наизусть я все их не помню).
Akina
21.04.2022 11:05А у вас есть Типовые запросы? Где вы их ведёте? Кто следит за актуальностью?
У меня... наверное есть - и в то же время нет.
У меня есть сервисная БД (на самом деле не одна, конечно, но другие существуют для других задач). В ней имеется куча "типовых" процедур и функций, выполняющих нужные операции. Всё проверено и вылизано, так что можно не бояться ещё и типичных ляпсусов копипаста. И, само собой, есть таблица, где всё это описано - имя, функционал, параметры и т.п.
Да, SHOW CREATE, само собой, доступна - так что если нужен именно код, а не функционал, то ничто не мешает...
Akina
21.04.2022 11:17Быстрый вход для новичков. Один файл - и вот ты уже можешь посчитать основные метрики.
Единообразие кода - новички перенимают представленный в Типовых запросах стиль.
"Нажми третью слева кнопку" - действие выполнено, понимания ноль. Быстрый вход? анализ стиля при копипасте? нет, Вы серьёзно?
ScapeKP Автор
21.04.2022 11:47Я не знаю, как у вас... Мы редко пишем одинаковый код. Даже если я выгружаю стандартные продажи, в одном случае это продажи в одном разрезе, в другом случае в другом разрезе, а в третьем с хитрой фильтрацией на 100 строк кода. Типовые запросы мне подскажут, из какой таблицы считать показатель и какой формулой, по какому полю джоиниться. Но переписывать всё равно придется каждый раз под свою задачу. Не получится запустить кнопкой и всё готово. Так что да, я серьезно. На код смотрят, его используют как часть своего кода, а не как вещь в себе.
А плохое понимание базы я внесла в минусы, да.
Хранение в процедурах - интересная мысль. Правда скорее подходит для сложной логики, которая выдает результат. Много маленьких вещей хранить так будет не удобно....
Akina
21.04.2022 15:03+1Правда скорее подходит для сложной логики, которая выдает результат.
Так никто не мешает натолкать параметров, которые управляют требуемыми отборами и разрезами, и формируют строку запроса, которая отдаст именно нужные данные в нужных видах, а затем выполнить этот запрос динамически. На самом деле не такая уж и сложная задача-то. Другое дело что вывод из ХП далеко не во всякой СУБД может использоваться как источник данных запроса (впрочем, временные таблицы есть везде), да и с оптимальностью у такого запроса обычно не всё ладно - но у меня это всё нивелируется тем, что решаемые задачи, как правило, разовые или длиннопериодические. К тому же построенный текст запроса всегда можно посмотреть - а потом оптимизировать и использовать уже его вместо процедуры.
Volrath
22.04.2022 11:04Мы для ad hoc запросов ведём репозиторий в корп гитлабе с ветками, мёрдж реквестами, код ревью и ссылками на соответствующие таски в жире. Менеджер доволен, аналитики ещё больше, потому что менеджер может даже сам переиспользовать код для новых задач, подобных старым. Ну и если типовая задача всплывает очень часто - она превращается в задачу на страничку в дэшборде или на рассылку ксв файла через airflow.
saipr
22.04.2022 21:27Теперь у меня другая забота — как организовать Типовые запросы при наличии нескольких баз данных.
А что с проектированием баз данных, с их нормализацией?
Может следует рассказать о нормальных формах, хотя про первые три.
mepihin
А в чем смысл статьи? Больше похоже на записку в блоге. Типовые запросы - это хорошо, если БД не меняется в процессе. То, что понимание структуры БД занижается - да, согласен, но есть ряд специальностей и задач, где это попросту не нужно. Вот например, сидит какой-нибудь HR и хочет выгрузить статистку там чего-то... Зачем ему структура БД? Ему сказали скрипт запустить, запустил, и все готово.
Для такого рода задач лучше иметь веб или десктоп приложение с графическим интерфейсом, чтобы пользователям было удобно искать нужные скрипты и настраивать из по необходимости.
ScapeKP Автор
Смысл в том, чтобы услышать, как это организовано у других, и, возможно, перенять опыт
Согласна, что зависит от отдела... Я про отдел аналитики. Пойду поправлю статью
InChaos
HR запускает скрипт??? Подготовленный Excel связанный с внешними данными, запускает и нажимает кнопочку "Обновить", какие скрипты? Как пример.
Я сторонник того, что тем кому нужны данные - надо давать данные а не собранный конструктор по их добыче, не заставлять их лезть в базу, выполнять скрипт потом еще и сами данные тащить куда то, там совершать какие то действия чтоб их использовать и т.д.
Если в работе нужны метрики, периодически списки, графики и т.д. то это делается нормальными инструментами. Excel как начальный уровень и далее PowerBI, Reporting Services и т.д. или аналоги.