Комментарии 10
А в чем смысл статьи? Больше похоже на записку в блоге. Типовые запросы - это хорошо, если БД не меняется в процессе. То, что понимание структуры БД занижается - да, согласен, но есть ряд специальностей и задач, где это попросту не нужно. Вот например, сидит какой-нибудь HR и хочет выгрузить статистку там чего-то... Зачем ему структура БД? Ему сказали скрипт запустить, запустил, и все готово.
Для такого рода задач лучше иметь веб или десктоп приложение с графическим интерфейсом, чтобы пользователям было удобно искать нужные скрипты и настраивать из по необходимости.
Смысл в том, чтобы услышать, как это организовано у других, и, возможно, перенять опыт
Согласна, что зависит от отдела... Я про отдел аналитики. Пойду поправлю статью
HR запускает скрипт??? Подготовленный Excel связанный с внешними данными, запускает и нажимает кнопочку "Обновить", какие скрипты? Как пример.
Я сторонник того, что тем кому нужны данные - надо давать данные а не собранный конструктор по их добыче, не заставлять их лезть в базу, выполнять скрипт потом еще и сами данные тащить куда то, там совершать какие то действия чтоб их использовать и т.д.
Если в работе нужны метрики, периодически списки, графики и т.д. то это делается нормальными инструментами. Excel как начальный уровень и далее PowerBI, Reporting Services и т.д. или аналоги.
Есть, храню в обычных текстовых файлах, разбитых по базам данных и тематике. Типовые запросы, а особенно краткие описания UDF. Очень полезно в случае, когда из нескольких баз, у каждой и которых есть свой хозяин, необходимо получить сводный отчет, не вдаваясь в структуру базы.
Плюс отдельные файлы с интересными редко используемыми скриптами из разных источников и различными реализациями стандартных запросов, скорость которых может сильно зависеть от состава данных. ( Для примера, на разных наборах данных время получения последних значений подчиненной таблицы сильно зависит от типа запроса, и сразу не скажешь, какой подойдет лучше в конкретном случае, а наизусть я все их не помню).
А у вас есть Типовые запросы? Где вы их ведёте? Кто следит за актуальностью?
У меня... наверное есть - и в то же время нет.
У меня есть сервисная БД (на самом деле не одна, конечно, но другие существуют для других задач). В ней имеется куча "типовых" процедур и функций, выполняющих нужные операции. Всё проверено и вылизано, так что можно не бояться ещё и типичных ляпсусов копипаста. И, само собой, есть таблица, где всё это описано - имя, функционал, параметры и т.п.
Да, SHOW CREATE, само собой, доступна - так что если нужен именно код, а не функционал, то ничто не мешает...
Быстрый вход для новичков. Один файл - и вот ты уже можешь посчитать основные метрики.
Единообразие кода - новички перенимают представленный в Типовых запросах стиль.
"Нажми третью слева кнопку" - действие выполнено, понимания ноль. Быстрый вход? анализ стиля при копипасте? нет, Вы серьёзно?
Я не знаю, как у вас... Мы редко пишем одинаковый код. Даже если я выгружаю стандартные продажи, в одном случае это продажи в одном разрезе, в другом случае в другом разрезе, а в третьем с хитрой фильтрацией на 100 строк кода. Типовые запросы мне подскажут, из какой таблицы считать показатель и какой формулой, по какому полю джоиниться. Но переписывать всё равно придется каждый раз под свою задачу. Не получится запустить кнопкой и всё готово. Так что да, я серьезно. На код смотрят, его используют как часть своего кода, а не как вещь в себе.
А плохое понимание базы я внесла в минусы, да.
Хранение в процедурах - интересная мысль. Правда скорее подходит для сложной логики, которая выдает результат. Много маленьких вещей хранить так будет не удобно....
Правда скорее подходит для сложной логики, которая выдает результат.
Так никто не мешает натолкать параметров, которые управляют требуемыми отборами и разрезами, и формируют строку запроса, которая отдаст именно нужные данные в нужных видах, а затем выполнить этот запрос динамически. На самом деле не такая уж и сложная задача-то. Другое дело что вывод из ХП далеко не во всякой СУБД может использоваться как источник данных запроса (впрочем, временные таблицы есть везде), да и с оптимальностью у такого запроса обычно не всё ладно - но у меня это всё нивелируется тем, что решаемые задачи, как правило, разовые или длиннопериодические. К тому же построенный текст запроса всегда можно посмотреть - а потом оптимизировать и использовать уже его вместо процедуры.
Мы для ad hoc запросов ведём репозиторий в корп гитлабе с ветками, мёрдж реквестами, код ревью и ссылками на соответствующие таски в жире. Менеджер доволен, аналитики ещё больше, потому что менеджер может даже сам переиспользовать код для новых задач, подобных старым. Ну и если типовая задача всплывает очень часто - она превращается в задачу на страничку в дэшборде или на рассылку ксв файла через airflow.
Теперь у меня другая забота — как организовать Типовые запросы при наличии нескольких баз данных.
А что с проектированием баз данных, с их нормализацией?
Может следует рассказать о нормальных формах, хотя про первые три.
Типовые запросы в SQL для всех. Плюсы и минусы