特集 SQL Server 2005の新機能「SQL CLR」（前編） SQL Serverプログラミングを革新するSQL CLRとは？ 中 博俊（Microsoft MVP 2005 - Visual C#） 2005/03/09
Page1 Page2 Page3

●インプロセスによるパフォーマンスの向上

　SQL CLRのプログラムは、これまでのADO.NETのプログラムと同様にC#やVisual Basic .NETで記述されるが、その実行はSQL Server 2005上で行われるため、実行時のパフォーマンス向上が期待できる。次にこの仕組みについて見ていこう。

　SQL CLRに限らずアプリケーションは、プロセス単位で動いている。.NETアプリケーションとSQL Serverとが同一のサーバ上で実行されていたとしても、アプリケーションとSQL Serverはそれぞれ違うプロセスで動作しているので、アプリケーションはそのプロセス境界を越えてSQL Serverへアクセスする必要がある。

　また通常のシステム構成では、.NETアプリケーション（クライアント）とSQL Server（サーバ）は異なるコンピュータ上にあるために、そのアプリケーションはネットワーク越しにデータベースへアクセスしなくてはならない。

　このように、ある境界（プロセスやネットワーク）を越えようとすると、そこで不要なオーバーヘッドが生じることになる。要するに、境界越えを行うと、データベース・アクセス処理が遅くなってしまい、効率が悪いのだ。

　この点に関してSQL CLRのプログラムは、次の図に示すように、T-SQL言語によるストアド・プロシージャと同様に、SQL Serverプロセス内で実行される。

境界を越えたデータベース・アクセスの問題

プログラムが境界を越えるときには必ずオーバーヘッドが発生する。のうち、境界によるオーバーヘッドが最も小さいが一番速く動作する。

外部PCからの接続例。ネットワーク境界を越えたアクセス。 　 同一PCからのプロセス境界を越えたアクセス。 　 同一プロセス内からの（境界を越えない）アクセス。

　この図ののように、同一のプロセスからのアクセス（つまり「インプロセス」の呼び出し）になると、呼び出しのための手続きは少なくなる。つまり、SQL処理を実行するプログラムがデータベース・サーバの近くであればあるほど、SQL処理の呼び出しにかかるオーバーヘッドが減るので、SQL CLRのプログラムは従来型のプログラムよりパフォーマンス面で有利になるということだ。

　なお上の図にあるのインプロセス呼び出しでは、T-SQLスレッドからの呼び出しと、SQL CLRスレッドからの呼び出しが記載されているが、実はこの両者のパフォーマンスには若干の違いがある。T-SQLではどのインデックスを利用してデータを取得するか、またどのテーブルとどのテーブルをJOINするかなどを、SQL Serverが解析してSQL処理の実行を最適化するようになっているので、データアクセスに関する部分では、SQL CLRよりもT-SQLのみで開発されたものの方がパフォーマンスが高いのである。従ってSQL CLRで実装するのが常に最善ということではない。この両者は状況に合わせてうまく使い分ける必要があるだろう。その使い分け指針については後で詳しく述べることにしよう。

●3つの権限セット

　SQL Server 2005に登録するSQL CLRのアセンブリには、3つの権限セット（＝アクセス許可セット）が適用される。これらの権限セットは、SQL CLRのアセンブリが、機能やリソース（例えば、ファイル、ネットワークなど）に対してアクセス可能かどうかを指定するためのものだ。これにより、システム管理者はSQL Serverで実行されるアセンブリの実行機能を制限できるようになり、SQL Serverやシステムの安全性を高めることができる。

権限セット	説明
セーフ（Safe）	DBアクセスのみを許可する権限セット。メモリとDBのデータだけが操作でき、そのほかのファイルや、ネットワーク、レジストリなどへはアクセスできない。これにより、SQL Server以外のシステム・リソース（レジストリなど）に対して安全なアセンブリであることが保証される。SQL Serverを実行している（サーバ側）ユーザーのセキュリティ・コンテキストを利用する
外部接続（External Access）	ファイル、ネットワーク、イベントログ、レジストリなどのシステム・リソースへのアクセスを可能にする権限セット。SQL CLRのアセンブリにある関数などを呼び出した（クライアント側）ユーザーのセキュリティ・コンテキストを利用する
無制限（Unrestricted）	Win32 APIを含めすべてに対してアクセス可能な権限セット
SQL CLRでアセンブリに対して適用される権限セット
通常はすべてセーフの権限セットで問題はない。ただし外部接続が必要な場合は往々にしてあると思うが、そのような場合は外部接続の権限セットを使うことになるだろう。

　これらの権限セットはアセンブリ単位で設定することになる。外部接続の権限セットを利用する場合には、SQL Serverのアクセス権限ではなく、呼び出し側のユーザーのセキュリティ・コンテキストが利用される。従って外部接続の権限セットを利用すると、場合によっては（＝ユーザーのセキュリティ・コンテキストの内容によっては）、不必要にセキュリティが緩くなってしまいかねないという問題がある。

　それを回避するために、1つの.NETアプリケーションに対してSQL CLRのアセンブリは1つという実装ではなく、セーフ用と外部接続用にアセンブリを分けて実装しておき、できるだけセーフ権限セットを利用するように努めるべきだろう。

●T-SQLとSQL CLRの使い分け

　ここまでSQL CLRの利点を説明してきたが、それではSQL Server 2005になると、もっぱらSQL CLRのみが使われるようになり、従来のT-SQL言語によるストアド・プロシージャは利用されなくなるのだろうか。実際にはそのようにはならず、状況によってT-SQL言語が使われたり、SQL CLRが使われたりするようになると思われる。この両者はどのように使い分ければよいのだろうか。

　その使い分け基準を知るには、T-SQL言語が得意な分野を考えるとよい。主にデータに単純にアクセスするようなSQL処理はやはりいままでのT-SQL言語に分がある。T-SQL言語ならば、SQL Serverの長い歴史で積み重ねられてきた、構文解析や最適化などの機能をフルに発揮できるからである。

　逆に、複雑な計算が多い場合や、外部のリソースにアクセスする場合、メモリ上で（取得データ同士の）特殊なマッチングを行う場合などには、SQL構文以外の一般的なプログラム・ロジックが利用できるSQL CLRの方が最適であるのは間違いない。

　この両者の使い分け指針を分かりやすく表したのが、次の図だ。

T-SQLとSQL CLRの使い分け基準（従来とSQL Server 2005以降の比較）

従来では、T-SQL言語で解決する部分とプログラムで解決する部分で実装個所を2分していたが、複雑なSQL命令文で行っていた個所や、データ・アクセスが多かったがプログラムで行っていた分野に、新たにSQL CLRという解決策が提供される。

　すでに書いたようにパフォーマンスの観点からも、従来のT-SQL言語によるストアド・プロシージャを完全に置き換えることは残念ながらできない。SQL CLRは、ストアド・プロシージャを置き換えるものではなく、ストアド・プロシージャとプログラムの双方の弱点を補完するものだ。ただし、SQL Server 2005以降のバージョンでは、ますますSQL CLRをターゲットにした拡張や機能強化が行われていき、SQL CLRの活動範囲がさらに広がる可能性は十分に秘めていると思われる。

■

　後編となる次回では、SQL CLRで実装できるプログラムの種類の違いや、Visual Studio 2005を利用したSQL CLRプログラムの開発方法などを解説していく。

INDEX
	［特集］SQL Server 2005の新機能「SQL CLR」（前編）
	SQL Serverプログラミングを革新するSQL CLRとは？
	1．従来のSQLプログラミングについて
	2．SQLプログラミングを革新するSQL CLRとは？
	3．SQL CLRの特長とストアド・プロシージャとの使い分け
	［特集］SQL Server 2005の新機能「SQL CLR」（後編）
	Visual Studio 2005でSQL CLRを実装してみる
	1．SQL CLRプログラミングの種類
	2．SQL CLRでHello World!を作成してみる
	3．Visual StudioによるSQL CLRの開発
	4．SQL CLRプログラムの実行

　

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）