PR

 最近になってデータベースを使い始めた人や,「SQL Server 2005」の新機能をチェックしている人にとって,共通言語ランタイム(CLR)とSQL Server 2005の関係は,ちょっとした謎に感じられることだろう。今回はデータベース技術者が知っておくべきCLRとSQL Serverの関わり合いに関する事実を紹介する。

 多くの.NETプログラマーは,CLRが本質的には.NETアプリケーションとOSの間に存在する「ランタイム・レイヤー」であることを知っている。CLRの仕事は,.NETプログラムから出された命令を,Windows OSが実行できるネイティブのWin32命令に変換することだ。CLRによってもたらされる主な利点は,アプリケーションのセキュリティと安定性が向上することだ。さらにCLRは,メモリー・リークやバッファ・オーバーフローのぜい弱性といった問題のあるアプリケーションからOSを守る上でも,力を発揮する。CLRの根底にある発想は新しいものではない。Javaとそれに関連するJava Virtual Machine(JVM)レイヤーが,この種のアーキテクチャを用いた最初のプログラミング言語である。

 それではCLRとSQL Serverは,どのようにかかわり合っているのだろうか?

 CLRは,SQL Server Expressを含むすべてのSQL Server 2005と統合されている。CLRオブジェクトを使ったデータベース・オブジェクトを作成することには,いくつかの重要な利点がある。まず第一に,Visual Basic(VB)やC#のような.NET言語を使うことによって,ストアド・プロシージャやトリガ,関数といったデータベース・オブジェクトの作成が可能になることだ。

 CLR登場前は,データベース・オブジェクトを作りたければ,T-SQLコマンドを使わなければならなかった。T-SQLは優れた集中指向のデータ検索能力を持っているものの,複雑なロジックや数学的演算の処理という点では,.NET言語の方が勝っている。CLRを使うことによって,SQL Serverにはデータベース・オブジェクト・プログラミング機能が追加されるのだ。

 第二に,T-SQLはリレーショナル・データベース指向の言語として設計されているため,リレーショナル・データベースの外側にあるリソースにアクセスする機能は含まれていない。言い換えると,T-SQLはファイル・システムやレジストリなどの読み出し・書き込みができないのである。

 そこでMicrosoftは,SQL Serverにリレーショナル・データベースの外側にあるリソースにアクセスする機能を付加するために「拡張ストアド・プロシージャ」という機能を追加した。これは本質的には,ネイティブのWin32プログラムであり,SQL Serverエンジンと同じメモリー上のプロセス空間内で作動する。拡張ストアド・プロシージャは,外部リソースへのアクセスを提供することによって,SQL Serverに足りない機能を補完している。しかしこれらのプロシージャはデータベース・エンジンと同じプロセスで動作するため,拡張ストアド・プロシージャにバグがあると,SQL Serverエンジンがダウンしてしまうのだ。これでは理想的な状態とは言えない。

 ところがCLRをSQL Server Expressに統合すると,これらの問題はどちらも解決する。CLRオブジェクトは,ファイル・システムやレジストリといった外部リソースにアクセスできる。だがCLRオブジェクトはCLRの制限内で作動するので,SQL Serverエンジンから独立している。従ってバグがあっても,コアのデータ・ベースエンジンの機能に影響を及ぼすことはない。

 SQL Server 2005の製品群にCLRを統合することによって,SQL Server Expressに機能が追加され,複雑なロジックを含むデータベース・オブジェクトを作成したり,外部リソースにアクセスしたりできるようになった。CLRの利点を引き出すには,何らかの.NET言語を使ってCLRオブジェクトをプログラムし,SQL Server Surface Area Configuration(SQL Serverセキュリティ構成)ツールを使って,CLR機能を有効にする必要がある(セキュリティ上の理由から,CLRはデフォルトでは無効になっている)。読者の皆様がCLRのことを把握し,CLRはSQL Serverの開発ツールの1つであるということを理解するのに,この記事が少しでも役に立てば幸いである。