使用する他のデータベースの内部ストアドプロシージャ用の中央CLRストアドプロシージャ/関数リポジトリライブラリを設定しますか？

C＃CLRで開発したコードを使用して、システム上のすべてのデータベースで使用できるようにしたいので、それぞれを信頼できるものに設定し、CLRをオンにして、それぞれに同じコードの束を保持する必要はありません。 。

管理およびセキュリティの観点からこれを行う最良の方法はありますか？CLR関数は、文字列ブレーカー、電子メール検証、url en / decode、base64などのように非常に基本的です。各データベースのdboスキーマのみが関数にアクセスできるようにしたいと思います。

1. これを行う簡単な方法はありますか？
2. また、CLR dllが埋め込まれているかどうか、およびデータベースを移動する場合、タグが一緒に移動するか、dllも移動する必要があるかどうかはわかりません。

ありがとう

当社では、まさにそのセットアップを行っています。CLRアセンブリを作成すると、作成したデータベース内にアセンブリのバイナリ表現が保存されます。これにより、いつでもデータベースを移動した場合に、それを持ち出すことができます（スクリプトを作成することもできます）。

数か月前にデータセンターが浸水し、いくつかのサーバーが水でいっぱいになりました。私がそれらを再構築したとき、私は前夜に取られたデータベースのバックアップのみを使用しました。これまでのところ、問題はありませんでした。

これがセキュリティの観点から正しいかどうかはわかりませんが、CLRプロシージャなどへのアクセスを許可する方法は、共有データベース内にロールを作成し、他のデータベースのユーザーをそのロールに追加することです。次に、CLRプロシージャの実行がロールに付与されます。

CLRが含まれているデータベースの外部にあるリソースへのアクセスなどを行おうとすると、アクセスの問題が発生する可能性がありますが、作成時にアセンブリにアクセス許可を設定できます。下のリンクには、ここで説明できるよりも多くの許可に関する情報があります。

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

これがあなたのお役に立てば幸いです。

アセンブリバイナリはblobとしてデータベースに保存されるため、データベースの場所を問わず持ち運びできます。CLRはインスタンスでのみ有効になります。そのためのデータベース固有の設定はありません。

いずれにせよ、なぜあなたはこれをやろうとしているのですか？

（私は議論になろうとはしていません。おそらくあなたのニーズを満たす別の方法で問題を解決できるかもしれないので、関与する動機を聞きたいです。）

アセンブリを共有データベースに置くことを除いて、これを簡単に行う方法はありません。

とはいえ、集中化する非常に説得力のある理由がある特定の状況がない限り、データベース中心のアーキテクチャを採用することは有利だと思います。その理由は、データベースの外にアセンブリ（またはそのことは何でも）を配置すると、環境に依存関係が作成されるためです。これは、MicrosoftがSQL Server 2012以降の包含データベースで構築しようとしている正反対のアプローチです。

• レプリケーションやクラスタリングなどの機能の使用が必要になると、この依存関係により、展開が非常に複雑になる可能性がありますが、トラブルシューティングやフェールオーバーの手順も複雑になる可能性があります。

• このアーキテクチャは、システムに不慣れな人々にはあまり明白ではありません（つまり、自己発見性が低く、自己文書化が少なくなります）。

• さまざまなデータベースでさまざまなセキュリティが必要になったり、バリエーションが関係するものが必要になったりすると、あなたは痛い目に遭います。

• これらのデータベースが顧客に展開される場合（そうではないように聞こえますが、完全を期すためにこれを言います）、これにより展開手順、メンテナンス、およびトラブルシューティングが複雑になります。

• すべてのデータベースがこのコードを共有するため、バグが導入された（または修正された）場合、データベースに依存するすべてのアプリケーションが破損する可能性があります。包括的な単体テストは絶対必要です。

同じ機能を必要とする複数のデータベースがある場合、関連する複製の量を減らす他の方法があります。これが演習のポイントだと思います。かなり複雑なCLRアセンブリでさえ、データベース自体のデータと比較して（ほとんどの場合）物理的なストレージスペースをあまり占有しないので、これを必要とする文字通り数千の小さなデータベースがない限り、それを有効な引数としては見ませんアセンブリ。

できることは、これらのデータベースの展開手順の他の部分を変更して、ソースの重複を減らすことです。たとえば、ソース管理のCLRコードの共通の場所からアセンブリをビルドして展開します。または、同じアセンブリをデータベースに展開するスクリプトを作成します。物事のこの部分を可能な限り自動化し、それは大したことではないでしょう。

私は提案していることはトレードオフであることに同意します、それはまだいくらかの重複があるからです、しかしそれは規定された標準に従わないアーキテクチャの実装に伴う否定とバランスをとらなければなりません。環境に最適なものを決定できるのはあなただけです。

他の2つの回答が正しく述べているように、アセンブリは特定のデータベースに読み込まれ、システム全体ではありません（ただし、assembly_id値はシステム全体で一意であると確信しています）。これは、ロードされる各データベースとともにバックアップおよびリストアされることを意味します。

また、（via ）のenabled/ disabled設定はシステム全体に適用されます。補足として、この設定はユーザーが作成した CLR機能専用です。一般的な意味でのCLRは、特定の組み込み機能が依存しているため、常に有効になっています。CLR Integrationsp_configure

ただし、ここでの他の2つの答えは有効なポイントですが、それらのポイントはSQLCLR固有ではなく、SQLCLRコードに固有のこの決定を行う要因については言及されていません。個々のデータベースにコードを展開する場合（多くのデータベースがあると仮定した場合）、潜在的なリソース競合の問題、潜在的なセキュリティ関連の問題など、考慮するメモリの問題があります。

一元化されたデータベースと個々のデータベースの展開を決定する際に、特にSQLCLRコードについて留意すべき包括的なリストを提供しました。ここにリストを複製するのではなく、次の回答をご覧ください（DBA.SEにもあります）。

パフォーマンスの観点からCLR関数をより適切に使用する方法（各DB内で繰り返すか、一般的な機能があります）

また、関連するメモで、データベースがに設定されている理由について質問しTRUSTWORTHY ONます。質問に記載されている機能（つまり、「文字列ブレーカー、電子メール検証、url en / decode、base64など」）はすべてSAFEアセンブリ内で可能です。どうしても必要なEXTERNAL_ACCESS場合UNSAFE以外は、perission_set値を使用しないでください。そして、それは機能のいくつかの数のために必要であれば、それらは別のアセンブリにする必要がありますのみが含まれているSAFEデータへのアクセスをしない任意のスカラー関数ようなコードととしてマークされているがIsDeterministic = trueあることのパフォーマンス上の利点を利用することができますが並行計画に参加できます。