SQL Server CLR хранимых процедур в задачах обработки данных - хорошо или плохо?

Question

Короче говоря - это хорошее дизайнерское решение для реализации большей части бизнес-логики в CLR хранимых процедурах ?

В последнее время я много о них читал, но не могу понять, когда их следует использовать, каковы лучшие практики, достаточно ли они хороши или нет.

Например, моему бизнес-приложению нужно

• парсинг большого текстового файла фиксированной длины ,
• извлечь несколько чисел из каждой строки в файле,
• в соответствии с этими числами применяются некоторые сложные бизнес-правила (включая сопоставление регулярных выражений, сопоставление с образцом по данным из многих таблиц в базе данных и т. Д.),
• и в результате этого расчета обновите записи в базе данных.

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

Это приложение является хорошим кандидатом для реализации классической 3-уровневой архитектуры: уровня данных, логического уровня и уровня графического интерфейса.

• Уровень данных будет обращаться к базе данных
• Уровень логики будет работать как служба WCF и реализовывать бизнес-правила, взаимодействуя с уровнем данных
• Уровень GUI будет средством связи между Логическим уровнем и Пользователем.

Теперь, подумав об этом проекте, я вижу, что большинство бизнес-правил могут быть реализованы в SQL CLR и сохранены в SQL Server. Я мог бы хранить все свои необработанные данные в базе данных, запускать там обработку и получать результаты. Я вижу некоторые преимущества и недостатки этого решения:

Плюсы

• Бизнес-логика работает близко к данным, что означает меньший сетевой трафик.
• Обрабатывать все данные одновременно, возможно, используя параллелизм и оптимальный план выполнения.

Против

• Рассеяние бизнес-логики: какая-то часть здесь, какая-то часть есть.
• Сомнительное дизайнерское решение, могут возникнуть неизвестные проблемы.
• Сложно реализовать индикатор прогресса для задачи обработки.

Мне бы хотелось услышать все ваши мнения о SQL CLR. Кто-нибудь использует это в производстве? Есть ли проблемы с таким дизайном? Это хорошо?

Answer 1

Я этого не делаю - CLR ins SQL Server отлично подходит для многих вещей (вычисление хэшей, манипулирование строками, которые просто всасывает SQL, регулярное выражение для проверки значений полей и т. Д.), Но сложная логика, IMHO, не имеет никакого отношения кбаза данных.

Это единственная проблема с производительностью, а также ОЧЕНЬ дорогое расширение.Плюс, либо я все это положил, либо - ну, - у меня есть серьезная проблема с техническим обслуживанием.

Answer 2

Как правило, вы, вероятно, не захотите этого делать, если не сможете получить существенное преимущество в производительности или если у вас есть веские технические причины для этого. Примером такой причины может быть пользовательская агрегатная функция.

Некоторые веские причины для использования хранимых процедур CLR:

• Вы можете воспользоваться уникальными возможностями технологии, такими как настраиваемая функция агрегирования.

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

• Вы хотите обернуть немного кода .Net или библиотеки .Net и сделать его доступным для кода SQL, работающего на сервере базы данных. Примером этого может служить сопоставление регулярных выражений из вопроса ОП.

• Вы хотите обмануть и обернуть что-то неуправляемое и ужасно небезопасное, чтобы сделать его доступным из кода SQL без использования XP. Технически Microsoft заявляет, что XP устарели, и многие установки отключают их по соображениям безопасности.
  
  Время от времени у вас нет возможности изменить код на стороне клиента (возможно, у вас отключен приложения), поэтому вам может потребоваться инициировать внешние действия из базы данных. В этом случае вам может потребоваться взаимодействие триггера или хранимой процедуры с внешним миром, например, запрос состояния рабочего процесса, запись чего-либо в файловую систему или (что более важно) отправка транзакции в систему удаленного мэйнфрейма через экран. библиотека скребков.

Недопустимые причины для использования хранимых процедур CLR:

• Незначительные улучшения производительности для того, что обычно делается на среднем уровне. Обратите внимание, что дисковый трафик, вероятно, будет намного медленнее сетевого трафика, если только вы не пытаетесь передавать огромные объемы данных через сетевое соединение.

• Звездочки CLR крутые, и вы хотите поместить их в свой C.V.

• Невозможно написать ориентированный на множество SQL.

Answer 3

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

Мои два цента.

НТН.