Перемещение C # в функциях процесса в функции SQL Server CLR

Question

Каковы ограничения, неожиданные ловушки и особенности производительности при переходе от внутрипроцессного кода C # к функциям SQL CLR?

В настоящее время у нас есть несколько процессов, интенсивно работающих с данными, которые работают очень быстро, используя в процессе C # Asp.net MVC проект без использования БД вообще. Производительность очень важна. Приложение использует статические данные в кэш-памяти и выполняет сложные операции для достижения окончательного результата. Обновление кэша представляет собой небольшую проблему, и мы рассматриваем возможность перемещения некоторых из этих процессов в запросы SQL Server, которые просто выводят конечный результат, так что на уровне приложения c # требуется меньше кэширования данных. Процессы сложны, и мы знаем, что переход к базе данных потребует широкого использования функций CLR SQL Server.

Мы видим много преимуществ в использовании базы данных, но обязательное использование функций CLR дает паузу по нескольким причинам:

Нет Azure: Функции SQL CLR не поддерживаются Azure ,

Высокая стоимость тестирования: Функции SQL CLR могут быть медленнее, и тестирование потребует значительных усилий

Небольшая база пользователей: Час поиска в Google показывает, что использование функций CLR несколько необычно, что делает поддержку сообщества (и, возможно, поддержку MS) проблемой.

Я хотел бы услышать от кого-то, кто переместил приложение C # из в процессе к функциям CLR.

В ваших ответах, пожалуйста, предположите, что требуются пользовательские функции SQL CLR.

Answer 1

Ваш

• Compile
• Установить
• Тест
• Debug

Процесс намного сложнее с функциями CLR Sql Server - я думаю, вы должны максимально автоматизировать это.

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

Однако, сказав, что «перенесите свой код в свои данные» иногда может быть очень хорошим вариантом.

Answer 2

Вы могли бы сделать это в Azure, если самостоятельно установите SQLServer и лицензируете его отдельно, как это было на месте, вместо того, чтобы использовать их параметры среды управляемого SQLServer с добавочной доплатой для включения SQLServer-as-a-service. Но тогда настройка всей остальной инфраструктуры вокруг поддержки базы данных будет на вас (резервные копии, HA и т. Д.)