CLR プロシージャを使用する理由。CLR プロシージャの重要性や、CLR プロシージャが唯一のソリューションである例はありますか?
5 に答える
正規表現を使用してSQLServerのデータフィールドの一部を検証するとします。今日まで、SQL Server 2008 R2でも、これはT-SQLコードだけでは事実上不可能です。
ただし、CLRストアドプロシージャまたはストアド関数の助けを少し借りれば、これは簡単なことです。
T-SQLは、データのセットを操作する場合に非常に強力です。そのために使用してください。
CLRは、文字列や日付の操作、外部サービス(WCF、Webサービス)の呼び出しなど、他の領域で非常に強力です。
したがって、T-SQLストアドプロシージャとCLRストアドプロシージャは優れた補完機能です。それぞれが、他のストアドプロシージャが特に得意ではない特定の一連の課題を解決します。
同様の質問に次の回答を投稿しました: Advantage of SQL SERVER CLR。ただし、少なくとも2つの回答で何かが言及されていることを考えると、ここに追加します.C#/ VB.netなどは、T-SQLよりも快適な言語であるため、T-SQLよりもSQLCLRを使用する理由にはなりません. T-SQL で何かを達成する方法がわからない場合は、まず T-SQL ソリューションを見つけるための支援を求めてください。存在しない場合は、CLR ルートに進みます。
SQL Server 内での SQLCLR / CLR 統合は、特定の問題 (すべてではない) の解決に役立つツールの 1 つです。純粋な T-SQL で実行できることよりも優れていることがいくつかあり、SQLCLR を介してのみ実行できることがいくつかあります。SQL Server Central の記事、SQLCLR レベル 1 への階段: SQLCLR とは何ですか? を書きました。(そこで記事を読むには無料の登録が必要です)、それはこの質問に対処します. 基本は次のとおりです (詳細については、リンクされた記事を参照してください)。
- ストリーミング テーブル値関数 (sTVF)
- 動的 SQL (関数およびトリガー内 - テーブルにアクセスでき
inserted
ますdeleted
) - 外部リソースへのアクセスの改善 / xp_cmdshell の置き換え
- データの受け渡しがより簡単に
- 結果セットの複数の列を取得する方が簡単です
- 外部依存関係なし (例: 7zip.exe)
- なりすましによるセキュリティの向上
- マルチスレッド機能
- エラー処理 (関数内)
- カスタム集計
- カスタム タイプ
- 状態の変更 (関数内で
OPENQUERY
/なしOPENROWSET
) - ストアド プロシージャの実行 (読み取り専用。関数内で
OPENQUERY
/なしOPENROWSET
) - パフォーマンス (注:これはすべての場合を意味するわけではありませんが、操作の種類と複雑さによっては、場合によっては確実に意味があります)
- 計算/文字列操作
- でマークされている場合、SQLCLR UDF
DataAccess = None
は並列実行プランで使用できますが、T-SQL UDF は並列プランを防ぎます。
- 出力 (つまり、SSMS の [メッセージ] タブに送信されるもの) をキャプチャできます (たとえば
PRINT
、重大度= 0 ~ 10) -- 記事でこれについて言及するのを忘れていました ;-)。RAISERROR
考慮すべきもう 1 つの点は、アプリケーション コードにアクセスするためだけに内部専用のカスタム画面を作成しなくても、DB が特定のビジネス ロジックを把握できるように、アプリケーションと DB の間でコードを共有できると有益な場合があることです。たとえば、顧客からデータ ファイルをインポートし、ほとんどのフィールドのカスタム ハッシュを使用して、その値を DB の行に保存するシステムに取り組んできました。これにより、アプリが入力ファイルから値をハッシュし、行に格納されているハッシュ値と比較するため、データを再度インポートするときに行を簡単にスキップできました。それらが同じである場合、どのフィールドも変更されていないことがすぐにわかったので、次の行に進みました。これは単純な INT 比較でした。しかし、ハッシュを行うためのアルゴリズムはアプリのコードにしか含まれていなかったため、顧客のケースをデバッグするため、または少なくとも 1 つのフィールドが変更された行 (アプリからの変更) にフラグを立てることで、一部の処理をバックエンド サービスにオフロードする方法を探すためかどうかに関係なく、新しいインポート ファイル内の変更を探すのではなく)、私にできることは何もありませんでした。これは、通常の処理ではなくても、DB にかなり単純なビジネス ロジックを含める絶好の機会でした。DB にエンコードされた値があり、その意味を理解することができないと、問題の解決が非常に難しくなります。これは、通常の処理ではなくても、DB にかなり単純なビジネス ロジックを含める絶好の機会でした。DB にエンコードされた値があり、その意味を理解することができないと、問題の解決が非常に難しくなります。これは、通常の処理ではなくても、DB にかなり単純なビジネス ロジックを含める絶好の機会でした。DB にエンコードされた値があり、その意味を理解することができないと、問題の解決が非常に難しくなります。
コードを記述せずにこれらの機能の一部を動作させることに関心がある場合は、無料バージョンのSQL# (私が作成者です) には、RegEx 関数、カスタム集計 (UDA)、カスタム タイプ (UDT) などがあります。
SQL Server では実行できない (または場合によってはマネージ コードほど実行されない) ことがいくつかあります。
- CLR にはRegExがあります。
- Web サービスを呼び出すことができます。
- CLR の方がパフォーマンスが優れています (たとえば、すべての行で多くの計算を行う必要がある場合)。
- コードの再利用
- 使い慣れた言語 (VB.Net、C# など) で記述します。
まあ、あなたが望むなら:
- データに対して複雑な操作を行う
- データに近づきたい (つまり、ASP.NET または Winforms アプリではない)、および
- SQL よりも C# でコードを記述したい場合。
これは、CLR プロシージャを使用する場合です。思いつくような例はありませんが、想像できるはずです。
- 編集:
想像できるのは、データをデータ ウェアハウス型の構造に変換することです。この場合、再フォーマットして少し分析を実行することをお勧めします。その場合、CLRでそれを行うのが適切かもしれません。(これがまさに私がやろうとしていることを示唆しているわけではありませんが、考慮される可能性があります)。
重要な数学計算を実行したり、外部 Web サービスなどを呼び出したりする場合、T-SQL から実行することはできません。これらを解決するには、.Net ストアド プロシージャまたは関数が非常に役立ちます。
また、CLR プロシージャを使用して集計関数を作成することもできますが、これは T-SQL では実行できませんでした。
もちろん、データ操作の場合は、T-SQL ストアド プロシージャの方がパフォーマンスが高く、記述も簡単です。