分散トランザクション管理とSQL CLR活用のヒント：SQL Server 2005を使いこなそう（7）（3/3 ページ）

5年ぶりのメジャーバージョンアップとなったSQL Server 2005。本連載では、SQL Server 2005への移行を検討しているデータベース管理者に向け、新規に実装されたさまざまな機能の詳細を紹介していく。（編集局）

[石橋潤一，株式会社システムインテグレータ] PC用表示

LINE

Hatena

前のページへ | 　　　　　　

SQL CLRを実際のプロジェクトでどのように生かすか

　ここまでの4回で、SQL CLRの基本的な考え方やコーディング方法について触れてきましたので、最後のまとめとしてSQL CLRを実際のプロジェクトでどのように生かしたらよいか考えてみましょう。

SQL CLRの要点

　まず、SQL CLRの要点を整理してみます。

慣れ親しんだ言語での開発
SQL CLRはC#やVB.NETなどのマネージドコードでストアドプロシージャやユーザー関数を開発することが可能です。プログラマにとっては、慣れた言語で開発できるため、生産性や品質の面で優位に働くでしょう。プロジェクト管理者にとっては、プログラマの教育や確保が比較的容易であるため、開発や保守のシーンでコスト削減が見込めるでしょう。
パフォーマンスの向上
SQL CLRはSQL Server 2005のプロセス内で実行されるため、データアクセスなどの面で、外部プログラムよりもパフォーマンスの向上が見込めます。Transact-SQLとの比較では、単純なデータアクセスであればTransact-SQLが勝っています。しかしながら、文字列操作や複雑な数値計算などの面で、SQL CLRが優位に立っています。
開発生産性の向上
.NET Frameworkで提供される膨大なクラスライブラリの利用、Visual Studio 2005との綿密な統合などにより、従来型のTransact-SQLに対し、開発生産性が大きく向上しています。また、すでにマネージドコードで書かれた独自ライブラリがあれば、それらを再利用することも可能でしょう。
セキュリティ面の懸念
SQL CLRでは、コードの動作を制限するために「権限セット」という概念を導入しています。ファイルやネットワークなど外部リソースへのアクセス、Win32APIなどアンマネージドコードの呼び出しを制限するものです。この権限セットとコードの管理が正しく行われていれば問題はありません。しかしながら、不用意に権限セットを緩めてしまえば、データベースの機密性や安定性に大きな問題を引き起こす懸念があります。

　これら要点の詳細は第4回「SQL CLRの仕組みとメリットを理解しよう」で取り上げています。SQL CLRはいくつかの面で優れた特性を持っていますが、その利用に当たっては注意すべき点もある、ということが分かります。

プロジェクトへの展開

　要点を確認できたところで、プロジェクトでの利用について考えてみます。プロジェクトと一言でいっても、大規模から小規模、パッケージ開発からカスタマイズまで多種多様なので、ここでは単純に開発の規模で分類して考えてみましょう。

低予算プロジェクト（予算が1000万円程度までの、納期が短く規模の小さなプロジェクト）
このようなプロジェクトでは、開発人員も限られており、優秀な人材を集められるとは限りません。しかしながら、納期と求められる品質は維持する必要があるため、SQL CLRの生産性の高さと慣れた言語を利用できる点が生きます。また、開発だけでなく、保守に掛けられるコストも少ないため、メンテナンス性の高さも利点となるでしょう。
中規模プロジェクト（予算が5000万円程度までの、比較的規模も大きいプロジェクト）
この規模までくれば、ある程度の人材を確保することができるはずです。また、パフォーマンスの面でシビアになるプロジェクトも多くなるため、Transact-SQLとSQL CLRをうまく使い分けたいところです。また、この規模のプロジェクトでは複数のデータベース、各種ファイルやネットワークなど多様なリソースが利用されるため、SQL CLRの外部アクセス可能な点をうまく活用できるはずです。
大規模プロジェクト（予算が5000万円から億単位に突入する、非常に規模の大きいプロジェクト）
このような規模のプロジェクトでは、生産性と品質の維持が非常に重要となります。筆者の勤める会社で扱うERPパッケージには、簡単なものから1万行を超えるものまで800個近いストアドプロシージャが存在します。これらのプログラムの開発と管理保守には非常に大きなコストが必要となり、プロジェクトにかかわる人数も多くなるため、全体のパフォーマンスを維持できなければ、死活問題に発展してしまいます。1万行のTransact-SQLをデバッグすると思うとぞっとしますよね。この規模まで達したプロジェクトでは、ビジネスロジックは基本的にSQL CLR化してしまってよいのではないかと考えています。例外的にクリティカルな処理はTransact-SQLで実装し、それをSQL CLRでラップしてしまうといった形が考えられます。

　教科書的な言葉で書けば、それぞれ適したシーンで利用しましょう、と一言で終わってしまうのですが、ここでは特にプロジェクトの規模に注目してSQL CLRの利用法について考えてみました。当然ながら一筋縄ではいかないプロジェクトも多く、SQL CLRの利用が適さない場合も多々あると思いますが、SQL CLRは基本的に「使える」技術なのではないかと考えています。特にビジネスロジックのSQL CLR化は、生産性と品質の両立という面で、大きな可能性を秘めているはずです。

まとめ

　SQL Server 2005に関する大きなトピックとして4回にわたってSQL CLRを取り上げました。使えると感じた方、使えないと感じている方、さまざまだと思います。SQL Server 2005を含め、SQL CLRは新しい技術なので評価が確定するのはまだまだこれからというところですが、開発者の皆さんにはこの新しい技術にぜひチャレンジしていただきたいと思います。

　次回はデータベースミラーリングを取り上げる予定です。お楽しみに！（次回へ続く）

著者紹介

石橋潤一

株式会社システムインテグレータ勤務。Web＋DBの業務アプリをメインに開発に携わる。＠IT連載記事「SQL Server 2005 CTPレビュー」執筆のほか、著書に『DBマガジン別冊　SQL Server 2005徹底活用ガイド』（翔泳社刊／共著）、『ASP.NET+SQL Server　ゼロからはじめるWebアプリケーション』（ソフトバンクパブリッシング刊／共著）。

「次回」へ

「SQL Server 2005を使いこなそう」バックナンバー