Всё так, на уровне СУБД ограничения ровно для этого и существуют - я сам топлю за «контроль на входе вместо разбора постфактум». Но у констрейнтов есть граница: они ловят то, что формализуется в схеме. Самые дорогие дубли - семантические: одна и та же железка заведена дважды под разными ID. PRIMARY KEY доволен, UNIQUE удовлетворен, а объект, по итогу, учитывается дважды. Плюс интеграции и миграции: данные стекаются из нескольких источников, где правила были иными или отключались на загрузке. Иначе бы в вакансиях крупных банков не писали «выявление дефектов данных» отдельной строкой в обязанностях))

По контексту отвечу прямо: в посте про оба мира - тренажёр в Excel, потом те же задачи в SQL-песочнице. И это, кстати, честная модель работы аналитика: чаще всего ты получаешь выгрузку из системы, которую проектировал не ты, и работа начинается ровно там, где закончились чужие ограничения 🤭

Тестовые с собесов - сильный источник, кстати: это же концентрат того, что работодатели реально считают важным, и у каждой задачи есть автор, который знает правильный ответ (в идеале). До M я пока не добрался, живу на формулах и сводных, но боль «доступа к ERP нема» знакома - у меня из-за этого вся тренировка на синтетике. А какое тестовое было самым хитровыпотрешенным из встреченных?

Потому никогда и не отказываю в тестовых. По тестовому можно понять, что кроется за красивым фасадом даже если нанимающий не может вменяемо объснить чего он конкретно хочет)))

По М приходится выкручиваться как умеешь. Я не умею в SQL вообще никак (пока дошел до стадии "завел учетку на гитхабе" 🤭). Если бы и знал, то "доступа к ERP нема". Синтаксис вроде простой, но опять же под это задачи нужны. Меня просто трех/пяти-этажные формулы заманали. На обработку полмиллиона строк уходит по часу :((( а таких расчетов по 6-8 штук на лист.

Самое-самое было когда пришлось нормализовать данные и найти корреляционные связи по трём различным параметрам и сделать выводы о необходимости централизации функции закупок шести заводов с учетом выявления транспортного хаба, который нивелирует расходы текущего длиннючего транспортного плеча. Проблема была в данных и их дополнительных параметрах - три параметра исходных условий превратились в бездонный колодец. Храни Господь регрессионно-корреляционный анализ.

Задача оказалась капец комплексная - задача с задачами.

Централизация закупок шести заводов через корреляции и поиск транспортного хаба - это уже не тестовое, а бесплатный консалтинг для них)) Понимаю, почему запомнилось.

Про полмиллиона строк по часу: почти всегда это этажные формулы на листе, которые пересчитываются целиком при каждом чихе. Если уже пишете на M - попробуйте агрегации делать прямо в Power Query до выгрузки на лист, разница в скорости обычно драматическая.

И про SQL обнадёжу: я сам прошёл его с нуля до оконных функций без всякого доступа к ERP - курс плюс песочницы типа sql-academy. Если осилили M с его синтаксисом, SQL покажется отпуском: те же join и group by, только слов втрое меньше.

Вот-вот, но при этом там правда тест был. Потому что исходные условия пришлось перевести в: "динамика очевидна по результатам, но следует расширить выборку".

Хуже. Одно неверное движение и все в пересчет пока не додумался в настройках поменять на итерационный пересчет. Я потому и полез в М и там уже все привычные манипуляции проворачивать стал. Потому что даже одну "формулу", если это вообще уже применимо к этой башне, расчёт даже ноут инженера-проектировщика (BIM-моделирование и все такое) за рабочий день не осилил. А в кьюри за 40-60 минут в легкую :) Вот я, турбопаскальщик, тогда выдохнул.

Спасибо большое! Звучит обнадеживающе. Может я и правда зря так долго его откладывал.

Турбопаскальщик, осиливший M, точно осилит SQL - после begin/end там вообще всё как отпуск)) А кейс про расчёт, который ноут BIM-инженера не осилил за день, а кьюри сделал за 40 минут - готовый аргумент для всех сомневающихся. Если начнёте SQL и где-то застрянете - пишите, покажу, на чём сам спотыкался)

Спасибо. Для меня очень ценно было это узнать! Теперь я себя чувствую более уверенно ☺️