Utworzenie centralnej biblioteki procedur przechowywanych / funkcji repozytorium CLR dla wewnętrznych procedur przechowywanych w innych bazach danych, które mają być używane?

Chciałbym użyć kodu, który opracowałem w języku C # CLR, aby był używany we wszystkich bazach danych w systemie, aby nie musiałem ustawiać każdej z nich jako wiarygodnej, włączać CLR i trzymać w jednym pakiecie tego samego kodu .

Czy istnieje najlepszy sposób na to z administracyjnego i bezpieczeństwa punktu widzenia? Funkcje CLR są bardzo podstawowe, takie jak przerywacze łańcuchów, sprawdzanie poprawności wiadomości e-mail, url en / decode, base64 itd. Chciałbym, aby tylko schemat dbo w każdej bazie danych miał dostęp do funkcji.

1. Czy jest jakiś prosty sposób to zrobić?
2. Również nie jestem pewien, czy dll CLR jest osadzony i jeśli przeniosę bazę danych, oznacza to tagi, czy też muszę przenieść dll.

Dzięki

W naszej firmie mamy dokładnie taką konfigurację. Podczas tworzenia zestawu CLR reprezentacja binarna zestawu jest przechowywana w bazie danych, w której go tworzysz. Umożliwia to zabranie go ze sobą (a nawet wykonanie skryptu) w przypadku przeniesienia bazy danych w dowolnym momencie.

Kilka miesięcy temu nasze centrum danych zostało zalane - napełniając kilka serwerów wodą. Kiedy je przebudowałem, użyłem tylko kopii zapasowych bazy danych wykonanych poprzedniej nocy. Do tej pory nie mieliśmy problemów .. (dotknij drewna!)

Nie jestem pewien, czy jest to słuszne z punktu widzenia bezpieczeństwa, ale sposób, w jaki udzielamy dostępu do procedur CLR itp., Polega na utworzeniu roli we wspólnej bazie danych, a następnie dodaniu użytkowników z innych baz danych do tej roli. Rola jest następnie przyznawana jako wykonywana na procesach CLR.

Mogą wystąpić problemy z dostępem, jeśli CLR próbuje wykonywać takie czynności, jak dostęp do zasobów poza bazą danych, w której się on znajduje, ale można ustawić uprawnienia do zestawu podczas jego tworzenia. Poniższy link zawiera o wiele więcej informacji na temat uprawnień, niż mogę to tutaj wyjaśnić:

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

Mam nadzieję, że to ci pomoże.

Plik binarny zestawu jest przechowywany jako obiekt typu blob w bazie danych, więc jest przenoszony gdziekolwiek baza danych. CLR jest włączony tylko w instancji - nie ma dla tego ustawień specyficznych dla bazy danych.

W każdym razie, dlaczego próbujesz to zrobić?

(Nie próbuję się kłócić; chcę tylko usłyszeć związane z tym motywy, ponieważ być może problem można rozwiązać w inny sposób, odpowiadający twoim potrzebom).

Nie ma na to łatwego sposobu, poza umieszczeniem zestawu we wspólnej bazie danych.

To powiedziawszy, uważam, że korzystne jest zastosowanie architektury skoncentrowanej na bazach danych, chyba że istnieje szczególna sytuacja, która ma bardzo ważne powody do centralizacji. Powodem, dla którego umieszczenie zestawu (lub cokolwiek w tym zakresie) poza bazą danych jest zależność w twoim środowisku. Jest to dokładnie odwrotne podejście, do którego Microsoft dąży z zawartymi bazami danych, począwszy od SQL Server 2012.

• Gdy zaczniesz korzystać z funkcji takich jak replikacja lub klastrowanie, ta zależność może potencjalnie zwiększyć złożoność wdrożenia, ale także rozwiązywanie problemów i procedury przełączania awaryjnego.

• Architektura ta jest o wiele mniej oczywista dla osób niezaznajomionych z systemem (tzn. Jest mniej samodzielna do odkrycia, a mniej do samodzielnego dokumentowania).

• Jeśli w końcu potrzebujesz różnych zabezpieczeń w różnych bazach danych lub czegoś, co wiąże się z odmiennością, jesteś w świecie bólu.

• Jeśli te bazy danych zostaną wdrożone u klientów (brzmi, jakby ich nie było, ale powiem to dla kompletności), zwiększy to złożoność procedury wdrażania, konserwacji i rozwiązywania problemów.

• Ponieważ wszystkie bazy danych współużytkują ten kod, jeśli zostaną wprowadzone (lub naprawione!) Błędy, może to potencjalnie uszkodzić wszystkie aplikacje, które korzystają z baz danych. Kompleksowe testy jednostkowe byłyby absolutną koniecznością.

Jeśli masz kilka baz danych, które wymagają tej samej funkcjonalności, istnieją inne sposoby zmniejszenia nakładania się duplikacji, co, jak zakładam, jest celem tego ćwiczenia. Nawet dość złożony zestaw CLR nie zajmie dużo fizycznej pamięci masowej w porównaniu do danych w samej bazie danych (prawie zawsze), więc nie uważam tego za prawidłowy argument, chyba że dosłownie masz tysiące małych baz danych, które tego potrzebują montaż.

Co możesz zrobić, to zmodyfikować inne części procedury wdrażania dla tych baz danych, aby zmniejszyć duplikację źródła. Na przykład kompiluj i wdrażaj zestaw ze wspólnej lokalizacji kodu CLR w kontroli źródła. Lub utwórz skrypt, który wdraża ten sam zestaw do baz danych. Zautomatyzuj tę część rzeczy tak bardzo, jak to możliwe, a to nie będzie wielka sprawa.

Zgadzam się, że to, co sugeruję, jest kompromisem, ponieważ nadal będzie pewne powielanie, ale musi to być zrównoważone z negatywnymi aspektami związanymi z wdrażaniem architektury, która nie jest zgodna z zalecanym standardem. Tylko Ty możesz zdecydować, co jest odpowiednie dla twojego środowiska.

Jak pozostałe dwie odpowiedzi poprawnie stwierdzają, zestawy są ładowane do konkretnej bazy danych i nie są ogólnosystemowe (chociaż jestem całkiem pewien, że ta assembly_idwartość jest unikalna dla całego systemu). Oznacza to, że są one tworzone i przywracane z każdej bazy danych, do której są ładowane.

Ponadto ustawienie enabled/ disabledprzez CLR Integration(via sp_configure) obejmuje cały system. Na marginesie, to ustawienie dotyczy tylko funkcji CLR utworzonych przez użytkownika ; CLR w ogólnym sensie jest zawsze włączony, ponieważ zależy od niego niektóre wbudowane funkcje.

To powiedziawszy, podczas gdy pozostałe dwie odpowiedzi tutaj robią ważne punkty, te punkty nie są specyficzne dla SQLCLR, i nie ma wzmianki o czynnikach, które są specyficzne dla kodu SQLCLR. Istnieją problemy z pamięcią, które należy wziąć pod uwagę, jeśli wdrażasz kod do każdej indywidualnej bazy danych (zakładając, że masz wiele baz danych), potencjalne problemy z rywalizacją o zasoby, potencjalne problemy związane z bezpieczeństwem itp.

Podałem szczegółową listę rzeczy, o których należy pamiętać, szczególnie w przypadku kodu SQLCLR przy podejmowaniu decyzji między scentralizowaną bazą danych a wdrożeniem pojedynczej bazy danych. Zamiast powielić listę tutaj, proszę zobaczyć następującą odpowiedź (także tutaj na DBA.SE):

Jak lepiej korzystać z funkcji CLR z punktu widzenia wydajności (powtórz w obrębie każdej bazy danych lub wykonaj funkcję ogólną)?

Również w powiązanej notatce zadałbym pytanie, dlaczego ustawiono dowolną bazę danych TRUSTWORTHY ON. Funkcjonalność zanotowana w pytaniu (tj. „Przerywacze ciągu, sprawdzanie poprawności wiadomości e-mail, url en / decode, base64 itp.”) Jest możliwa w obrębie SAFEzestawu. Nie należy stosować albo EXTERNAL_ACCESSczy UNSAFEperission_set wartości, chyba że jest to absolutnie konieczne. A jeśli jest to konieczne dla pewnej liczby funkcji, powinny one znajdować się w osobnym zestawie, który zawiera tylko SAFEkod taki, że wszelkie funkcje skalarne, które nie uzyskują dostępu do danych i są oznaczone jako IsDeterministic = truebędą mogły skorzystać z korzyści płynących z wydajności w stanie uczestniczyć w równoległych planach.