Ключевое слово "привычки" :))
Мой кейс:
под задачи BI в компании накатал за пару дней витринку, ничего сложного: простые агрегации, конвертация валют и с десяток простых бизнесовых метрик.
Тема настолько зашла, что в течение следующих 1.5 месяцев ко мне почти каждый день приходили и просили добавить "всего лишь ещё один" расчётный показатель. В итоге sql-код стал простынкой из >500 строк, и не смотря на то, что я старался соблюдать принципы модульности с кучей with () as, никто кроме меня и ребят из моей команды, которые приложили руку, разобраться в нём, не то чтобы не может, а просто не хочет.
Пример: понадобилось добавить расчёт кумулятивной суммы метрики. В df это можно сделать просто поменяв sum на cumsum. В sql не так, нужно извращаться. Попробовав наиболее распространённый рецепт - получили падение производительности на 2 порядка. План запроса для такой простыни, как вы понимаете отдаёт другую нечитаемую простыню. На просьбу к нашему dba-щику помочь, он посмотрел на нашу простыню, перекрестился и теперь просто обходит нас стороной.
Каждая новая мелкая доработка стала очень дорогой и стрёмной, почти всегда ломающей, то что уже работало. Продебажить классическими средствами нельзя. Юнит-тестов нет, потому что нет юнитов, короче кошмар.
В итоге застопил все тикеты на доработку и медитативно переписываем всё на df
Тут помогает процедурный подход
Каждый блок это 1 преобразование который порождает новую таблицу
А dataflow решается через airfow
