Разработка SQL в целом не подходит для парадигмы разработки программного обеспечения: она не может использоваться повторно, не приводит к определениям DRY и ее трудно поддерживать. Но самое главное, что большинство методов, которые улучшают этот статус-кво и приводят к улучшению качества кода, - это проблемы времени выполнения. И проблема времени выполнения SQL не имеет ничего общего с неоптимальной конструкцией кода в коде, она приводит к плохим планам, которые дают результаты в десятки и сотни раз медленнее, чем оптимальный план. Другими словами, когда основа определения запроса DRY без разумных блоков приводит к плану сканирования таблицы, который выполняется 10 секунд, а уродливое одноразовое представление имеет лучший план, который выполняется за 10 мс, вы забываете все о DRY и идете с уродливым но быстрый просмотр. Различия во времени выполнения между хорошим планом и плохим планом слишком велики.
Вот почему с разработкой SQL хорошие проекты заканчиваются несколькими хорошо настроенными запросами, которые постоянно измеряются и проверяются на производительность. Мне грустно говорить, но по моему опыту, чем «здоровее» код SQL был от классического кода (DRY, многоразового использования, поддерживаемого), тем больше проблем у него было в реальном мире при работе с большим объемом данных. Мне бы очень хотелось, чтобы был простой способ развертывания многократно используемых блоков SQL, которые можно было бы собрать в сложные структуры. Просто так не работает. Я достаточно знаю о том, как работает оптимизация SQL-запросов, чтобы понять, что оптимизаторы запросов смотрят на полученный сложный блок в целом, и они не могут использовать внутренние блоки как «единицы работы», им поручено оптимизировать конечный конечный результат. А оптимизация таких сложных запросов с учетом путей доступа к данным, затрат на ввод-вывод, размера данных, вероятностей распределения значений столбцов просто очень-очень сложна, на несколько порядков сложнее, чем задача, скажем, оптимизатор C # должен сделать.
Мой совет: держите несколько сложных представлений, которые были протестированы и настроены. Свобода составления базового строительного блока будет быстро нарушена, и вы обнаружите это слишком поздно.