Зачем у 1С-ников просят знание SQL⁠⁠

Поведай свой путь в 1с пожалуйста. Не упускай даже самые грязные подробности )) (с)

Бывают задачи по интеграции 1с со сторонними БД на скуле, вот там как раз и нужно его знание. Например, я себе в группу когда искала еще программиста, у меня в заявке для HR тоже было указано, что опыт работы с SQL будет большим плюсом. Это вполне нормально, хоть и не всем надо.

Смотря где спрашивают. Обычно рядовому 1с-нику глубокие знания SQL не нужны. Но бывают высоконагруженные системы, где может не один человек заниматься только тем, что анализировать запросы, планы запросов, настраивать индексы и т.д. Вот в плане запроса и будет SQL

В СКЛ план запроса зависит от правильно выстроенного порядка условий в where или правильного порядка join с учётом индексов. Запрос 1С транслируется в sql-запрос соответствующей СУБД (даже анализаторы планов запросов СУБД имеются для отладки в инструментарии 1С-дибишников) и для написания нормальных запросов в 1С очень полезны те же самые навыки, принципы и подходы, которые используются при написании запросов SQL. Причём я бы сказал, что полезен любой диалект -- хоть Мускул, хоть Файрбёрд, хоть Оракл. Не обязательно Слон или МикрософтвенныйСкуль, на которых 1С, собственно, и ездит. Причём тут не надо быть настоящим дибишником, пишущим вьюшки, триггеры, хранимые процедуры, не нужен ДДЛ. Достаточно только собственно запросов, но сами запросы надо уметь писать хорошо. Потому что иначе будут те же проблемы, что и в любой другой системе.
Причём коварство по-тупому написанного запроса в том, что на тестовой базе с 10 документами и 100 записями в справочнике всё летает и проблем нет, а потом на реальной базе в лучшем случае товарный чек 10 минут формируется из-за того, что к выборке из хранимой процедуры с косячными параметрами в 1500000 записей иннерджойнится таблица с 1000 записей и по условию остаётся 3 строки в результирующей выборке. А в худшем к таблице в 50 000 записей лефтджойнится без условий другая таблица с 80 000 записей и полученная выборка объёмом 5 терабайт записывается во временную таблицу до исчерпания свободного диска -- чтобы потом из неё 1000 строчек отобралась (в конце года такую багу в ЕРП поймали при расчёте себестоимости).

В 99.9% случаев это HRы копируют описания вакансий из одной в другую без включения мозга. В 1С есть SQL ? ну типа есть. значит в вакансии пусть будет.
В 0.1% случаев там будут и хранимки и курсоры и прочая хреноверть из-за попыток заставить 1С работать с очень большими данными противоестественным образом.