Menyiapkan pustaka penyimpanan prosedur / fungsi yang tersimpan di CLR pusat untuk procs tersimpan internal di basis data lain untuk digunakan?

Saya ingin menggunakan kode yang saya kembangkan di C # CLR untuk digunakan di semua database pada sistem sehingga saya tidak harus mengatur masing-masing agar dapat dipercaya dan mengaktifkan CLR dan menyimpan banyak kode yang sama di dalam masing-masing .

Apakah ada cara terbaik untuk melakukan ini dari sudut pandang administrasi dan keamanan? Fungsi CLR sangat mendasar seperti pemecah string, validasi email, url en / decode, base64, dan lain-lain. Saya hanya ingin skema dbo di setiap basis data untuk dapat mengakses fungsi.

1. Apakah ada cara sederhana untuk melakukan ini?
2. Juga saya tidak jelas apakah dll CLR tertanam dan jika saya memindahkan database, itu tag bersama, atau apakah saya harus memindahkan dll juga.

Terima kasih

Di perusahaan kami, kami memiliki pengaturan yang tepat. Saat Anda membuat unit CLR, representasi biner dari unit tersebut disimpan di dalam basis data tempat Anda membuatnya. Ini memungkinkan Anda untuk membawanya bersama Anda (dan bahkan menghapusnya) jika Anda memindahkan database kapan saja.

Beberapa bulan yang lalu pusat data kami kebanjiran - mengisi beberapa server penuh air. Ketika saya membangunnya kembali, saya hanya menggunakan cadangan db yang telah diambil malam sebelumnya. Sejauh ini kami tidak memiliki masalah .. (menyentuh kayu!)

Saya tidak yakin apakah ini hal yang benar untuk dilakukan dari perspektif keamanan tetapi cara kami memberikan akses ke procs CLR dll adalah untuk membuat peran dalam database bersama, dan kemudian menambahkan pengguna dari database lain ke peran itu. Peran ini kemudian diberikan dieksekusi pada procs CLR.

Mungkin ada masalah akses jika CLR mencoba melakukan hal-hal seperti mengakses sumber daya di luar database yang terkandung di dalamnya tetapi Anda dapat mengatur izin pada perakitan ketika Anda membuatnya. Tautan di bawah ini memiliki lebih banyak informasi mengenai izin daripada yang bisa saya jelaskan di sini:

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

Saya harap ini membantu Anda.

Biner rakitan disimpan sebagai gumpalan di basis data, sehingga dibawa ke mana pun basis data pergi. CLR hanya diaktifkan pada instance - tidak ada pengaturan khusus database untuk itu.

Bagaimanapun, mengapa Anda mencoba melakukan ini?

(Saya tidak berusaha untuk berdebat; Saya hanya ingin mendengar motif yang terlibat, karena mungkin masalahnya dapat diselesaikan dengan cara yang berbeda yang memenuhi kebutuhan Anda.)

Tidak ada cara untuk melakukan ini dengan mudah, kecuali menempatkan perakitan di database bersama.

Yang mengatakan, saya akan berpikir itu menguntungkan untuk merangkul arsitektur database-sentris, kecuali ada situasi tertentu yang memiliki alasan kuat untuk memusatkan. Alasan mengapa menempatkan majelis (atau apa pun) di luar database menciptakan ketergantungan di lingkungan Anda. Ini justru pendekatan sebaliknya yang sedang dikembangkan oleh Microsoft dengan Contained Databases yang dimulai pada SQL Server 2012.

• Ketika Anda mulai perlu menggunakan fitur seperti replikasi atau pengelompokan, ketergantungan ini berpotensi menambah kerumitan dalam penyebaran, tetapi juga untuk pemecahan masalah, dan prosedur failover.

• Arsitektur ini jauh kurang jelas bagi orang yang tidak terbiasa dengan sistem (yaitu, itu kurang dapat ditemukan sendiri, dan kurang mendokumentasikan diri).

• Jika pada akhirnya Anda membutuhkan keamanan yang berbeda di database yang berbeda, atau apa pun yang melibatkan variasi, Anda berada dalam dunia yang terluka.

• Jika basis data ini digunakan untuk pelanggan (sepertinya tidak akan, tetapi saya akan mengatakan ini untuk kelengkapan), ini menambah kerumitan pada prosedur penyebaran, pemeliharaan, dan pemecahan masalah.

• Karena semua basis data akan membagikan kode ini, jika ada bug yang diperkenalkan (atau diperbaiki!), Ini berpotensi menghancurkan semua aplikasi yang bergantung pada basis data. Pengujian unit komprehensif akan menjadi keharusan mutlak.

Jika Anda memiliki beberapa database yang membutuhkan fungsi yang sama, ada cara lain untuk mengurangi jumlah duplikasi yang terlibat, yang saya asumsikan adalah inti dari latihan ini. Bahkan perakitan CLR yang cukup kompleks tidak akan memakan banyak ruang penyimpanan fisik dibandingkan dengan data dalam database itu sendiri (hampir selalu), jadi saya tidak melihat itu sebagai argumen yang valid kecuali jika Anda memiliki ribuan database kecil yang membutuhkan ini majelis.

Apa yang bisa Anda lakukan adalah memodifikasi bagian lain dari prosedur penyebaran untuk database ini untuk mengurangi duplikasi sumber. Misalnya, membangun dan menggunakan unit dari lokasi umum kode CLR dalam kontrol sumber. Atau, buat skrip yang menyebarkan rakitan yang sama ke database. Otomatiskan bagian ini sebanyak mungkin, dan itu tidak akan menjadi masalah besar.

Saya setuju bahwa apa yang saya sarankan adalah tradeoff, karena masih akan ada duplikasi, tetapi itu harus diimbangi dengan negatif yang terlibat dengan penerapan arsitektur yang tidak mengikuti standar yang ditentukan. Hanya Anda yang dapat memutuskan apa yang tepat untuk lingkungan Anda.

Karena dua jawaban lainnya menyatakan dengan benar, Assemblies dimuat ke dalam basis data tertentu dan tidak untuk seluruh sistem (meskipun saya cukup yakin bahwa assembly_idnilainya adalah unik untuk seluruh sistem). Ini berarti bahwa mereka dicadangkan, dan dipulihkan, dengan setiap basis data tempat mereka dimuat.

Juga, pengaturan enabled/ melalui (melalui ) adalah seluruh sistem. Sebagai catatan tambahan, pengaturan itu hanya untuk fungsionalitas CLR yang dibuat pengguna ; CLR dalam arti umum selalu diaktifkan karena fungsi bawaan tertentu bergantung padanya.disabledCLR Integrationsp_configure

Yang mengatakan, sementara dua jawaban lain di sini memang membuat poin yang valid, poin-poin itu tidak spesifik SQLCLR, dan tidak disebutkan faktor-faktor dalam membuat keputusan ini yang khusus untuk kode SQLCLR. Ada masalah memori yang perlu dipertimbangkan jika Anda menggunakan kode ke setiap basis data (dengan asumsi Anda memiliki banyak basis data), potensi masalah pertentangan sumber daya, potensi masalah terkait keamanan, dll.

Saya telah memberikan apa yang harus menjadi daftar komprehensif hal yang perlu diingat, khususnya untuk kode SQLCLR, ketika memutuskan antara database terpusat vs penyebaran basis data individu. Daripada menduplikat daftar di sini, silakan lihat jawaban berikut (juga di sini di DBA.SE):

Bagaimana cara lebih baik menggunakan Fungsi CLR dari sudut pandang kinerja (ulangi di dalam setiap DB atau memiliki fungsi umum)?

Juga, pada catatan terkait, saya akan mempertanyakan mengapa ada basis data yang diatur TRUSTWORTHY ON. Fungsionalitas yang dicatat dalam Pertanyaan (yaitu "pemecah string, validasi email, url en / decode, base64, dll") semuanya dimungkinkan dalam SAFEMajelis. Anda seharusnya tidak menggunakan nilai perission_set EXTERNAL_ACCESSatau UNSAFEkecuali benar-benar diperlukan. Dan jika diperlukan untuk sejumlah fungsi, maka fungsi tersebut harus berada dalam Majelis terpisah yang hanya berisi SAFEkode sehingga fungsi skalar apa pun yang tidak melakukan akses data dan ditandai karena IsDeterministic = trueakan dapat memanfaatkan manfaat kinerja dari menjadi dapat berpartisipasi dalam rencana paralel.