Должен ли аналитик уметь работать с хранимыми процедурами? И какой это уровень?

Хз. Лично мне никогда не нужны были. Пока

В вакансиях просто требования бывают. !Хранимые процедуры - обязательно! ) поэтому решил спросить

Цитирую кого-то из этого чата
1. Простые - c join, cte, order by, group by, агрегатными функциями, case when, функции даты и времени
2. Средней сложности - оконные функции, pivot, учёт ограничений версионности данных
3. Сложные - оптимизация: использование грамотное хинтов, анализ планов запросов, работа с многопоточными базами, логирование

у меня уровень "сложных" это 15 страниц ворда 12 шрифтом текста запроса. На моей практике был 93-страничный запрос - отчёт по расчёту премии менеджеров по продажам за период, с учётом продаж/возвратов/допродаж/плана и факта/индивидуальных условий сделок (когда скидки могли убивать маржу)/себестоимость/косвенные затраты.
У всех разный уровень сложных задач :)

Мне вот интересно, а как проверить что там нет ошибки?

Тут даже вопрос не юниттестов, а хотя бы как это ревьюить?

Ни у кого не возникает вопросов к надежности таких решений?))

Приветки! Разрабов можно поискать?) Нужен backend.

Так проверяется все такое - отдельно расписывается строка формул, берутся варианты итогов и проверяются данные и вычисления. И 93 страницы запроса отлаживать это АД, так как только погружение в запрос идёт 3 месяца.

Подробно тут. Компания ок) выходит на раунд B.
https://www.notion.so/Backend-7db4999f7d6c4847b262284e42da0d52

Я надеюсь, 93 страницы это с учетом временных таблиц и тд, это же не единая простыня?))

Единая простыня. Это выполнение запроса "единоразовое", так как это отчёт, и промежуточные сохранения временных таблиц были запрещены, иначе бы было необходимо накладывать блокировки на таблицы на чтение (даже на грязное) что не хотели делать

Мде...

когда ты подневольный исполнитель, пусть даже и с хорошим опытом - ты всё равно выполняешь "работу", а не обсуждаешь.
Если делать правильно, то надо было создавать отдельные таблицы в которых хранить промежуточные начисления по каждой продаже (там было ещё разделение внутри отчёта на менеджерскую премию и премию руководителя как накопительную), чтобы потом из этих таблиц тянуть данные. Или делать такие отчёты ночью и затем предоставлять результат по почте (отчёт формировался около 1 часа, несмотря на то что было огромное количество индексов и оптимизаций плана запросов). Но было как было. Компания очень известна на рынке продажи софта в РФ

SQL запросы в ворде?)

это бекап

Нет, конечно. Это было ctrl-c - ctrl-v в ворд, чтобы понять сколько там текста, ну и похвастаться перед коллегами само собой

мы обычно меряемся просто в кол-ве строк)

количество строк производит не такой эффект, чем когда человек открывается длиннющий файл в котором огромные лестницы подзапросов

Сколько человеко-часов ушло на это?

file.sql ?)