Многие проблемы, требующие денормализации и / или последовательных операций, могут быть исключительно хорошо обработаны CLR и могут быть использованы для значительного повышения производительности без ущерба для удобства использования на стороне SQL (много). Вместо того, чтобы полностью полагаться на основанные на множестве или итеративные операции, вы можете использовать гибридный подход, использовать основанное на множестве решение для больших выборок и переключиться на итерационную модель для узких циклов.
Встроенные hierarchyid и геопространственные (то есть geography) типы в SQL Server 2008 являются хорошими примерами проблемы денормализации. Оба содержат (почти) произвольно большой объем данных, которые трудно нормализовать без ущерба для производительности - вам потребуется использовать рекурсию или курсоры, чтобы выполнить с ними какую-либо значимую работу иначе, или использовать крысиное гнездо триггеров и / или запланированных задач вести таблицу денормализации.
Другая проблема, которую я решил с типами CLR, - встроенное сжатие. Это может звучать как бессмысленное или академическое упражнение, но когда ваши полностью нормализованные данные помещаются в терабайты, сокращение размера на 80-90% значит много. В SQL теперь есть свое собственное встроенное сжатие, а в SQL 2005 был vardecimal, и это тоже хорошие инструменты, но алгоритм «минимизации» с учетом предметной области может быть в несколько раз более эффективным с точки зрения как загрузки процессора, так и степени сжатия. Очевидно, что это относится не к каждой проблеме, но к некоторым.
Еще одна очень распространенная проблема, часто встречающаяся на этом сайте, - это создание последовательности на лету - например, последовательности последовательных дат. Распространенными решениями являются рекурсивные CTE, таблицы статических последовательностей и малоизвестные таблицы spt_values, но простой CLR UDF работает лучше, чем любая из них, и предлагает гораздо большую гибкость.
Последнее в моем списке: пользовательские потоковые агрегаты также очень полезны, особенно для всего, что связано со статистикой. Есть некоторые вещи, которые вы просто не можете составить из встроенных агрегатов SQL, такие как медианы, взвешенные скользящие средние и т. Д. UDA также могут принимать несколько аргументов, чтобы вы могли их параметризировать; технически агрегат не гарантирует получение данных в каком-либо определенном порядке в текущей версии SQL Server, но вы можете обойти это ограничение, передав ему ROW_NUMBER в качестве дополнительного аргумента и использовать его для реализации практически любой оконной функции (пусть агрегат выплюнет UDT, который затем может быть преобразован в таблицу).
На самом деле очень обидно, как мало примеров действительно полезных приложений SQL-CLR; Выполните поиск в Google, и вы получите 10 миллионов результатов, каждый из которых требует какой-то глупой конкатенации строк или регулярных выражений. Они полезны, но потратьте несколько минут, чтобы узнать, в частности, о пользовательских UDT и UDA SQL, и вы увидите множество вариантов их использования в ваших собственных приложениях. Конечно, не сходите с ума - подумайте о том, есть ли лучшее решение в чистом SQL, - но не стоит их сбрасывать со счетов.