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

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

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

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

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

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

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

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

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

Плюсы:

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

Минусы:

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

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


sql-server n-tier-architecture clrstoredprocedure
person Gart    schedule 20.05.2010    source источник
comment
+1 за хороший вопрос. Сам не знаю, что ответить, поэтому пока послушаю... ;)   -  person Lucero    schedule 20.05.2010

Ответы (3)


arrow_upward
4
arrow_downward

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

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

person TomTom    schedule 20.05.2010

arrow_upward
2
arrow_downward

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

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

ХТН.

person Brian Mains    schedule 20.05.2010

arrow_upward
2
arrow_downward

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

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

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

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

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

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

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

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

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

  • CLR sproc — это круто, и вы хотите поместить их в свое резюме.

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

person ConcernedOfTunbridgeWells    schedule 20.05.2010