.NET Frameworkとの統合で、強力に生まれ変わったSQL Server 2005：Microsoft Tech・ED 2005 Yokohama

2005年11月17日に日本でのラウンチが正式に決まったVisual Studio 2005とSQL Server 2005は、切っても切れない関係となっている。さまざまな意味で連携されている2つのツールだが、SQL Serverにとって、.NET Frameworkと統合されたことの意味は大きい。

[下村恭（ハンズシステム），ITmedia]

　SQL Server 2005は、.NET Frameworkが現れてから初めてバージョンアップされるSQL Serverとなる。現行のバージョンであるSQL Server 2000が使われ始めたころには、.NET Frameworkは存在しなかった。そういった意味では、待ちに待ってのバージョンアップであり、ユーザーにとっては待った甲斐のある進化を遂げていると言えるだろう。

　今回のバージョンアップでさまざまな機能強化が行われているSQL Serverだが、その中でも際立ったものが、SQL CLRと呼ばれる.NET FrameworkのCLR（Common Language Runtime）との統合だ。実際にCLRとSQL Serverは、どのように統合されているのだろうか。

　SQL CLRでは、CLR上で実行される.NETアセンブリをSQLストア上に格納する。その上で、T-SQLでラッピングしT-SQLのオブジェクトとして見えるようにする。このため、SQL Serverの外部からアクセスしてきた場合、クライアントはT-SQLのオブジェクトにアクセスしているのか、.NETアセンブリに含まれるオブジェクトにアクセスしているのかの区別はつかない。

SQL CLRはSQL ServerとCLRの統合で実現できた機能だ。CLR上で実行される.NETアセンブリは、従来のT-SQLのオブジェクトで包まれるため、SQL Serverにアクセスしてきたクライアントからは、T-SQLオブジェクトとの違いがわからないようになっている

　従来のSQL Server上のプログラム開発は、T-SQLと呼ばれるANSI SQL言語を拡張した、いわゆるSQL言語で行われており、作成できるオブジェクトもプロシージャ、ファンクション、トリガという基本的なものだけであった。もちろん、複雑で高度な処理を実現するための方法として、拡張ストアドプロシージャという抜け道的な方法もないわけではなかったが、プログラミングが困難であった上、C/C++言語による開発と、アンマネージドコードがもたらす結果として、システムクラッシュの危険もあった。

　また、普通にストアドプロシージャを作成する場合でも、開発ツールと呼べるようなものは準備されておらず、管理ツールであるEnterprise Managerや、非力なクエリアナライザを使用していたため、開発効率がよいとは言えなかった。さらに、T-SQL言語の実行はインタープリタで行われるため、パフォーマンスも同様によいとは言いがたい。

　一方、SQL CLRでは.NET言語すべてが使用可能であるうえ、コンパイルされたコードを実行するため、パフォーマンスの点でT-SQLよりも有利と言える。加えて、プロシージャ、ファンクション、トリガ以外にも、集計やデータ型を作成することが可能となる。マネージドコードによる実行のため、システムのセキュリティも維持することが可能だ。

　SQL Server 2005ではCLRと統合されたことで、Visual Studioという強力な開発環境が利用でき、.NET Frameworkの持つ強力なクラスライブラリを利用できるようになる。特に、従来のSQL Serverの開発言語であったT-SQLが苦手とするファイル操作やログ操作、ネットワーク接続、正規表現に代表される文字列操作などは、.NETの恩恵をフルに受けられる部分と言えるだろう。

T-SQLとSQL CLRの比較：インタープリタ言語であるT-SQLとVB.NET／C#などの.NET対応のコンパイル言語、作成可能なオブジェクトという点を比べると、SQL CLRがいかに強力な機能なのかが分かる

　SQL CLRを利用すると、VB.NETやC#といった最近のオブジェクト指向言語によるスキルを活かしたコーディングが可能となる。.NET Frameworkの強力なライブラリを活用でき、Visual Studioの開発生産性を享受でき、パフォーマンスの向上も期待できる。まさによいこと尽くめのように思える。しかし、T-SQLを忘れてすべてをSQL CLRに移行できるわけではないことに注意が必要だ。

　Tech・Edのセッションでは、適材適所の使用を勧めていた。では、どういう場面でSQL CLRを使用すべきなのだろうか。

　真っ先に挙げられていたのが、従来、拡張ストアドプロシージャで実現していた部分だ。前述のとおり、開発が困難であったりアンマネージドであるがゆえ、メモリリークなど実行時にリスクが伴うため、拡張ストアドプロシージャそのものを避けるべきだからだ。

　次にSQL CLRが勧められているのは、ユーザー定義関数だ。ユーザー定義関数は、おもに演算に使用されており、従来ではT-SQLで無理やりコーディングされていることが多かったため、.NET言語による容易なプログラミングが可能であり、コンパイル言語による高いパフォーマンスを生かせるポイントだからだ。

　さらに、従来はあまり利用されていなかったようだが、テーブル値関数にはT-SQLよりもSQL CLRを利用することが勧められている。.NETのクラスライブラリを利用して外部リソースにアクセスするなど、利用できる機会が今後増えていくだろう。また、T-SQLではテンポラリテーブルを使用しなければならず、パフォーマンスが出なかったが、SQL CLRではオンメモリで処理できるため、パフォーマンスの点でも有利だ。

　逆に、クエリー処理などのデータアクセス処理に関しては、従来どおりT-SQLを使用することが勧められている。これは、SQL CLRでは、データプロバイダを使用しなければ、データにアクセスできないため、T-SQLに比べてオーバーヘッドが大きいためだ。

　SQL CLRを使用する上での注意点もある。データ型について、SQLの型と.NET言語での型が完全に一致させられない点（特にNULLの扱い）や、例外処理（SQL CLRの中で例外が起きても、クライアントには常に6522のエラーコードが返るため、区別がつかない）、オブジェクトの名前空間の問題（T-SQLでラップされるため、命名規則はT-SQLに従うことになる）など、CLR上で実行される.NETアセンブリといえども、T-SQLに縛られる部分もかなりあるからだ。

　とはいえ、CLR対応となったことで開発者が受ける利点は多い。SQL CLRを使う場所を見極め、うまく利用することで、開発生産性の向上、パフォーマンスの向上、信頼性や堅牢性の向上に大きく寄与することは間違いない。