Каковы ограничения сборок CLR для SQL Server 2008? - PullRequest
4 голосов
/ 06 февраля 2011


Я планирую некоторые отчеты с довольно большой нагрузкой вычислений, которые, как мне кажется, лучше перенести в пользовательскую сборку .NET, загруженную в Microsoft SQL Server. Компании, которые будут использовать это, будут использовать только выпуски SQL Server Enterprise, поэтому никаких проблем с поддержкой функций.

Вопрос:
Это действительно хорошая идея?
Я хочу экспортировать эту функцию, потому что хочу использовать такие функции, как:

  • Многопоточность (количество потоков будет минимальным между обработанными объектами и максимальным числом, установленным в файле конфигурации. Я не знаю другого верхнего предела, который я должен указать.)
  • Неуправляемый код (библиотеки C ++ для потоковой обработки)
  • Иногда даже COM-взаимодействие или команды оболочки, хотя это менее вероятно.

Будут ли они работать нормально? Есть ли какие-либо ограничения, о которых я должен знать, в моем случае?

1 Ответ

2 голосов
/ 27 мая 2011

Все, что вы перечисляете, возможно с некоторыми ограничениями.Атрибуты Host Protection позволяют получить доступ к созданию потоков, но запрещают доступ к Thread.Join и т. Д. Подробнее об этом можно узнать на msdn

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

Также нет ограничений на методы и классы в сборках, загружаемых в службы Reporting Services.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...