Все знают, что новые разработчики пишут длинные функции. По мере продвижения вы становитесь лучше, разбивая свой код на более мелкие части, и опыт учит вас тому, как это делать.
Введите SQL. Да, способ мышления кода SQL отличается от процедурного мышления кода, но этот принцип кажется вполне применимым.
Допустим, у меня есть запрос, который принимает форму:
select * from subQuery1 inner join subQuerry2 left join subquerry3 left join join subQuery4
Использование некоторых идентификаторов или дат и т. Д.
Эти подзапросы сами по себе сложны и могут содержать собственные подзапросы. Ни в каком другом контексте программирования я бы не подумал, что логика для сложных подзапросов 1-4 принадлежит моему родительскому запросу, который объединяет их все. Это кажется настолько простым, что эти подзапросы должны быть определены как представления, точно так же, как они были бы функциями, если бы я писал процедурный код.
Так почему же это не обычная практика? Почему люди так часто пишут эти длинные монолитные SQL-запросы? Почему SQL не поощряет широкое использование представлений так же, как процедурное программирование поощряет широкое использование функций. (Во многих корпоративных средах создание представлений - даже не то, что легко сделать. Требуются запросы и одобрения. Представьте, что другим типам программистов приходилось отправлять запрос каждый раз, когда они создавали функцию!)
Я подумал о трех возможных ответах:
Это уже распространено, и я работаю с неопытными людьми
Опытные программисты не пишут сложный SQL, потому что предпочитают решать сложные проблемы обработки данных с помощью процедурного кода
Что-то другое