Налаштування центральної бібліотеки сховищ процедур / функцій CLR для внутрішніх збережених програм у інших базах даних, які слід використовувати?

Я хотів би використовувати код, який я розробив у C # CLR, щоб використовувати його у всіх базах даних в системі, щоб мені не довелося встановлювати кожну надійну і вмикати CLR і зберігати купу одного і того ж коду всередині кожного .

Чи є найкращий спосіб зробити це з адміністративної точки зору та з точки зору безпеки? Функції CLR є дуже основними, як переривники рядків, перевірка електронної пошти, URL-адреса / декодування, base64 та ін. Я хотів би, щоб лише схема dbo у кожній базі даних мала можливість отримати доступ до функцій.

1. Чи є простий спосіб це зробити?
2. Крім того, мені не зрозуміло, чи вбудований DLL-файл CLR, і якщо я переміщу базу даних, вона позначає теги, чи потрібно також переміщувати dll.

Спасибі

У нашій компанії у нас є точні налаштування. Коли ви створюєте збірку CLR, двійкове представлення збірки зберігається в базі даних, в якій ви її створюєте. Це дає змогу взяти її з собою (і навіть скриптувати її), якщо ви перемістите базу даних у будь-який момент часу.

Пару місяців тому наш центр обробки даних затопився - наповнивши кілька серверів, наповнених водою. Коли я відновлював їх, я використовував лише резервні копії db, які були зроблені напередодні ввечері. Поки у нас проблем не було .. (торкніться деревини!)

Я не впевнений, чи правильно це робити з точки зору безпеки, але спосіб, яким ми надаємо доступ до програм CLR тощо, - це створити роль у спільній базі даних, а потім додати до цієї ролі користувачів із інших баз даних. Потім роль виконується в програмах CLR.

Можливо, можуть виникнути проблеми з доступом, якщо CLR намагається виконувати такі речі, як ресурси доступу за межами бази даних, в якій вона міститься, але ви можете встановити дозвіл на збірку під час створення. Нижче на посиланні є набагато більше інформації щодо дозволів, ніж я можу пояснити тут:

http://msdn.microsoft.com/en-us/library/ms345101.aspx

Я сподіваюся, що це вам допоможе.

Бінарний збірник зберігається у вигляді бази в базі даних, тому він переноситься туди, куди йде база даних. CLR увімкнено лише в екземплярі - для цього немає специфічних баз даних.

У будь-якому випадку, чому ви намагаєтеся це зробити?

(Я не намагаюся бути аргументативним; я просто хочу почути мотиви, які стосуються, тому що, можливо, проблему можна було б вирішити іншим способом, який відповідає вашим потребам.)

Неможливо зробити це легко, крім того, як скласти збірку у спільну базу даних.

Зважаючи на це, я думаю, що вигідно використовувати архітектуру, орієнтовану на бази даних, якщо тільки не існує конкретної ситуації, яка має дуже вагомі причини централізації. Причина полягає в тому, що розміщення збірки (або будь-чого з цього питання) поза базою даних створює залежність у вашому оточенні. Це якраз протилежний підхід, який Microsoft вибудовує із вміщеними базами даних, починаючи з SQL Server 2012.

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

• Ця архітектура набагато менш очевидна людям, незнайомим із системою (тобто вона менш самовідкрита і менш самодокументована).

• Якщо вам потрібна різна безпека в різних базах даних або будь-що, що стосується змін, ви потрапили у світ шкоди.

• Якщо ці бази даних розгортаються для клієнтів (це здається, що їх не буде, але я скажу це для повноти), це додає складності процедурі розгортання, технічного обслуговування та усунення несправностей.

• Оскільки всі бази даних поділять цей код, якщо будь-які помилки введені (або виправлені!), Це може потенційно зламати всі програми, які покладаються на бази даних. Комплексне тестування одиниць було б абсолютно необхідним.

Якщо у вас є декілька баз даних, які потребують однакової функціональності, існують інші способи зменшення кількості дублювання, що, як я вважаю, є суть вправи. Навіть досить складна збірка CLR не займе багато фізичного простору для зберігання даних порівняно з даними в самій базі даних (майже завжди), тому я не вважаю це вірним аргументом, якщо у вас буквально не є тисячі крихітних баз даних, які потребують цього складання.

Що ви можете зробити, це змінити інші частини процедури розгортання цих баз даних, щоб зменшити дублювання джерела. Наприклад, побудувати та розгорнути збірку із загального місця розташування коду CLR у контролі джерела. Або створити сценарій, який розгортає ту саму збірку до баз даних. Автоматизуйте цю частину речей якомога більше, і це не буде великою справою.

Я погоджуюся, що те, що я пропоную, є компромісом, тому що все одно буде певне дублювання, але це повинно бути врівноважене з негативами, пов'язаними з впровадженням архітектури, яка не відповідає встановленому стандарту. Тільки ви можете вирішити, що підходить для вашого оточення.

Як правильно вказано в двох інших відповідях, збори завантажуються в певну базу даних і не є загальносистемною (хоча я досить впевнений, що assembly_idзначення є унікальним для всієї системи). Це означає, що вони створюються резервними копіями та відновлюються з кожною базою даних, в яку вони завантажуються.

Крім того, enabled/ disabledналаштування CLR Integration(через sp_configure) є загальносистемним. Як бічне зауваження, це налаштування лише для створених користувачем функцій CLR; CLR у загальному розумінні завжди вмикається, оскільки від нього залежить певна вбудована функціональність.

Це означає, що в той час, як інші два відповіді тут складають вагомі моменти, ці пункти не є специфічними для SQLCLR, і немає жодних згадок про фактори прийняття цього рішення, які є специфічними для коду SQLCLR. Існують проблеми з пам'яттю, які слід враховувати, якщо ви розгортаєте код у кожній окремій базі даних (якщо у вас є багато баз даних), можливі проблеми з вмістом ресурсів, потенційні проблеми, пов'язані з безпекою тощо.

Я визначив, що має бути вичерпним переліком речей, які слід пам’ятати, спеціально для коду SQLCLR, коли приймаються рішення між централізованою базою даних та окремим розгортанням бази даних. Замість того, щоб дублювати список тут, дивіться наступну відповідь (також тут, на DBA.SE):

Як краще використовувати функцію CLR з точки зору продуктивності (повторити всередині кожної БД або мати загальну функцію)?

Також у відповідній примітці я б поставив під сумнів, чому встановлюється будь-яка база даних TRUSTWORTHY ON. Функціональність, зазначена у запитанні (тобто "вимикачі рядків, перевірка електронної пошти, URL-адреса / декодування, base64 тощо"), можлива в межах SAFEасамблеї. Ви не повинні використовувати або EXTERNAL_ACCESSчи UNSAFEperission_set значення , якщо це абсолютно необхідно. І якщо це необхідно для деякої кількості функцій, то вони повинні бути в окремій збірці, яка містить лише SAFEкод, такий, що будь-які скалярні функції, які не мають доступу до даних, і позначені як такі IsDeterministic = true, що зможуть використати користь від продуктивності здатні брати участь у паралельних планах.