Являются ли хранимые процедуры CLR более предпочтительными, чем хранимые процедуры TSQL в SQL 2005+?

Question

Мое текущее представление - нет, я предпочитаю хранимые процедуры Transact SQL, потому что они имеют меньший вес и (возможно) более высокую производительность, в то время как процедуры CLR позволяют разработчикам справляться со всеми видами неприятностей.

Однако в последнее время мне пришлось отлаживать некоторые очень плохо написанные TSQL хранимые процессы. Как обычно, я обнаружил многие проблемы из-за того, что первоначальный разработчик не имел реального опыта работы с TSQL, они были ориентированы на ASP.NET / C #.

Таким образом, использование процедур CLR, во-первых, предоставит гораздо более знакомый набор инструментов для разработчиков этого типа, а во-вторых, средства отладки и тестирования более мощные (т. Е. Visual Studio вместо SQL Management Studio).

Мне было бы очень интересно услышать ваш опыт, так как кажется, что это не простой выбор.

Answer 1

Есть места для хорошо написанного, хорошо продуманного T-SQL и CLR. Если какая-то функция вызывается не часто и если она требует расширенных процедур в SQL Server 2000, CLR может быть вариантом. Также может быть привлекательным запускать такие вещи, как вычисления прямо рядом с данными. Но решение плохих программистов с помощью новых технологий звучит как плохая идея.

Answer 2

CLR хранимые процедуры не предназначены для замены запросов на основе набора. Если вам нужно выполнить запрос к базе данных, вам все равно потребуется вставить SQL в код CLR, как если бы он был встроен в обычный код. Это было бы пустой тратой усилий.

Хранимые процедуры CLR предназначены для двух основных целей: 1) взаимодействие с ОС, например чтение из файла или удаление сообщения в MSMQ, и 2) выполнение сложных вычислений, особенно если у вас уже есть код, написанный на. NET язык, чтобы сделать расчет.

Answer 3

Размещение CLR в SQL Server дает разработчикам баз данных более гибкие возможности в способах выполнения задач. Как уже упоминалось, SQL отлично подходит для операций и модификаций наборов данных . Любой, кто проделал обширную разработку больших приложений со сложными правилами для бизнеса / домена, скорее всего, скажет вам - попытка применить некоторые из этих правил с использованием чистого SQL (иногда в виде одного макропросмотра) может стать по-настоящему кошмарной.

Есть только определенные задачи, которые лучше решать процедурно или не по назначению. Имея возможность использования кода .NET для разрушения последовательности логики, операции запроса могут стать проще для чтения и отладки. Используя хранимые процедуры CLR, я могу сказать, что с помощью отладчика вы сможете легко понять, что происходит на уровне базы данных.

Только один пример, мы часто используем хранимые здесь процедуры CLR в качестве «шлюза» для динамических поисковых запросов. Скажите поисковый запрос, который может иметь до 30 различных параметров поиска. Пользователи, очевидно, не используют все 30 из них, поэтому переданная структура данных будет иметь 30 параметров, но в основном это DBNULL. На клиентской стороне нет опции для генерации динамического оператора по очевидным причинам безопасности. Результирующий динамический оператор генерируется внутри, не опасаясь внешних «дополнений».

Answer 4

Помимо доступа к файловой системе (где CLR-проки имеют очень явное преимущество), я бы использовал T-SQL-проки. Если у вас есть особенно сложные вычисления, вы можете поместить эту часть в функцию CLR и вызывать ее из своего процесса (в udf я обнаружил, что интеграция CLR действительно блестящая). Затем вы получаете преимущества интеграции CLR для этой конкретной части вашей задачи, но сохраняете как можно больше своей сохраненной логики процесса в БД.

Answer 5

Я считаю, что эти два не эквивалентны ... подходят друг к другу.
Интеграция с CLR предполагает постепенный отказ от "расширенных хранимых процедур" прошлого. У нас есть некоторые из них на нашем рабочем месте ... по существу блоки обработки / логики над данными SQL, которые было слишком сложно / невозможно сделать с помощью обычные БД Хранимые процедуры / Т SQL. Поэтому они записали это как расширенные хранимые процедуры в C ++ DLL, которые можно вызывать аналогичным образом. Теперь они сняты с производства, и замена CLR является заменой

• Хранимые процедуры в БД: если это можно сделать в хранимых процедурах T SQL, сделайте это.
• CLR Хранимые процедуры: если логика слишком сложна или утомительна для выполнения с помощью T SQL ... если для ее решения потребуется меньше строк кода CLR (манипулирование строками, сложная / настраиваемая сортировка или фильтрация и т. Д.) ) используйте этот подход.

Answer 6

Обычно вы используете CLR, если у вас есть что-то, что не требует большого взаимодействия с базой данных. Допустим, вы анализируете или декодируете значение. Это проще сделать в CLR, а затем вернуть значение.

Попытка сделать запрос compelx в CLR - это просто не тот путь.

Кстати, это не изменилось и в 2008 году.

Answer 7

Учитывая то, что вы сказали, я бы предпочел, чтобы вы правильно обучили девооперов t-SQl и базам данных, чем позволили бы им наносить значительно больший ущерб производительности, позволяя им выполнять задачи t-sql в CLR. Разработчики, которые не понимают базы данных, используют это в качестве предлога, чтобы избежать действий, которые являются наилучшими для производительности базы данных, потому что они хотят принять то, что они считают более легким маршрутом.

Answer 8

Мы столкнулись с ситуацией с функцией CLR, которую вызывали тысячи раз в обычном процессе SQL. Это был процесс для импорта данных из другой системы. Функция проверила данные и хорошо обработала нули.

Если мы выполнили операцию в TSQL, процесс завершится примерно через 15 секунд. Если мы использовали функцию CLR, процесс завершился через 20 - 40 минут. Функция CLR выглядела более элегантно, но, насколько мы могли судить, был запуск при каждом использовании функции CLR. Поэтому, если у вас большая операция, выполненная с использованием одной функции CLR, это нормально, поскольку время запуска мало по сравнению со временем для операции. Или, если вы вызываете функцию CLR небольшое количество раз, общее время запуска для всех вызовов этой функции будет небольшим. Но будьте осторожны с петлями.

Кроме того, для удобства обслуживания лучше не иметь больше языков, чем вам действительно нужно.

Answer 9

На странице в электронной документации SQL Server Books перечислены следующие преимущества:

• Лучшая модель программирования. Языки .NET Framework во многих отношениях более богаты, чем Transact-SQL, предлагая конструкции и возможности, ранее недоступные разработчикам SQL Server. Разработчики могут также использовать возможности библиотеки .NET Framework, которая предоставляет обширный набор классов, которые можно использовать для быстрого и эффективного решения проблем программирования.

• Повышение безопасности и защиты. Управляемый код выполняется в общеязыковой среде выполнения, размещенной в компоненте Database Engine. SQL Server использует это для обеспечения более безопасной и безопасной альтернативы расширенным хранимым процедурам, доступным в более ранних версиях SQL Server.

• Возможность определять типы данных и агрегатные функции. Пользовательские типы и определяемые пользователем агрегаты - это два новых объекта управляемой базы данных, которые расширяют возможности хранения и запросов SQL Server.

• Оптимизированная разработка через стандартизированную среду. Разработка баз данных интегрирована в будущие выпуски среды разработки Microsoft Visual Studio .NET. Разработчики используют те же инструменты для разработки и отладки объектов базы данных и сценариев, что и для написания компонентов и сервисов .NET Framework среднего или клиентского уровня.

• Потенциал для повышения производительности и масштабируемости. Во многих ситуациях модели компиляции и исполнения языка .NET Framework обеспечивают улучшенную производительность по сравнению с Transact-SQL.

Answer 10

Это всегда сводится к правильному инструменту для работы, так что это действительно зависит от того, чего вы пытаетесь достичь.

Однако, как правило, вы правы, что CLR-процессы имеют большие издержки и никогда не будут выполнять операции над множествами, такие как T-SQL. Моя рекомендация - делать все это в T-SQL, если только то, что вам нужно, не станет слишком сложным в T-SQL. Затем постарайтесь сделать так, чтобы подход T-SQL работал. :-)

CLR-проки хороши и имеют свое место, но их использование должно быть исключением, а не правилом.