連載：［完全版］究極のC#プログラミング Chapter17　LINQ to SQL 川俣 晶 2010/04/14
Page1 Page2 Page3 Page4 Page5 Page6

17.2 SQL Serverのワナ

　話の枕として、なぜSQL Serverが“使えない”のかというところから説明を始めよう。

　まず、RDB（リレーショナルデータベース）という技術そのものが「設計変更に弱い」という致命的な欠陥を有する、という話は次に示す記事に書いたので繰り返さない（これはp.31で触れた連載と同じものである）。興味があれば、目を通してほしい。

Database Expert「XMLデータベース開発方法論」
http://www.atmarkit.co.jp/fdb/index/index-db.html#xmldbdev

　ここで述べるのは、Microsoft SQL Serverという具体的な製品についての話である。

　ここでは以下のような事例があると仮定して話を進めよう。

　A君はテキスト処理に興味があるC#プログラマーである。彼が扱う膨大な文書には決まった構造はなく、例外処理も多い。そのため、きっちりとしたスキーマを作成しなければ扱えないRDBとはあまり縁がなく、スキーマレスでXMLを使うことが多かった。

　あるとき、A君は次のようなWebアプリケーションの開発を依頼された。

• 10万件の「名前、日付、得点」のデータがある
• 特定の名前や日付に対応する得点を検索して出力したい

　さて、ここでA君は考え込んだ。10万件のデータを含むXML文書であっても、解析にはそれほど時間はかからない。しかし、Webアプリケーションともなれば、立て続けにいくつもリクエストが来る可能性がある。リクエストが1回来るごとに、10万件のXML文書の解析を行っていたら、サーバーの処理能力を超えてしまうかもしれない。

　そこで、A君はもっと素早く処理できるデータベースの採用を検討することになる。ここで最初にA君の目に入るのは、SQL Serverということになる。Visual Studioのインストール時に、Express Editionという無償で使用できるSQL Serverの小規模版が同時にインストールできるからだ。Visual Studioのユーザーなら、興味はなくとも名前ぐらいは聞いたことがあるだろう。

　そこでA君は考えてみる。わずか3項目しかないシンプルなデータ構造で、データ量もわずか10万件だ。大規模な設計変更などありえないぐらいのシンプルさであるし、駄目なら、つぶして作り直してもたいした手間にはならない。設計変更に弱いというRDBの弱点は、この場合ほとんど関係ないだろう。逆に、正しく使えばデータの安全性は高まるし、性能も上がりそうである。

　そう……。ちょっとデータを入れておくだけの用途なら、RDBの弱点は必ずしも弱点ではないのだ。そこで、A君はSQL Server Express Editionの採用を決断して開発に着手する。

　ところが、A君は即座に自分の無力さを痛感することになる。

　SQL Serverの世界は、それ自体が1つの独立した世界を構成するほどに大きい。膨大なドキュメントがあって、かつ、それらは部外者には容易に読めない言葉で書かれている。どれほどC#の経験があっても、それだけではSQL Serverには歯が立たないのだ。しかも、SQL Serverはプロ用のツールとして進化してきた関係上、複雑で高度な機能が大量に揃っている。そのような前提で設計されている以上、機能制限版のExpress Editionであっても、決して素人にわかりやすくはない。

　A君はドキュメントの量と質のダブルパンチに打ちのめされつつ、ようやく初心者向けのチュートリアルにたどり着くことになる。

　そして、A君はようやくSQL Server Management StudioやVisual Studioにビルドインされたサーバーエクスプローラを使って、手動でデータベースの作成や管理ができるようになる。テーブルを作成し、いくつかのテストデータを入力するぐらいのことは、なんとか達成できるだろう。

　ここで、A君はようやくホッとすることができる。なぜなら、データベースさえ用意できれば、そこから先はA君がよく知っているC#プログラミングでデータベースを操作できるからだ。

　だが、A君の前にはさらなる絶望が待ちかまえている。なぜなら、C#プログラムからデータベースを操作するというのは、実はC#プログラミングではないからだ。C#とはまったく別の言語である問い合わせ言語「SQL」をC#プログラム中に埋め込み、それを実行させる必要があるのだ。

　A君はまったく新しいSQLという言語を見よう見まねで書き始める。そして、テストプログラムがやっと完成し、コンパイルも通るようになった。しかし、それを実行してもエラーが出て動作しない。SQLで書かれたクエリは、C#コンパイラから見れば単なる文字列でしかないので、コンパイル時にはいっさい内容が検証されず、構文エラーが検出されるのは、実行時まで遅延される。

　しかも、A君にはエラーメッセージの内容が理解できない。エラーメッセージの意味を理解するためには、しばしばSQLやデータベースに関する広範囲の基礎知識が必要とされるが、チュートリアルをかじった程度のA君にそれだけの知識があろうはずもない。エラーの原因がわからなければ、コードを直しようがない。

　絶望したA君は、もう二度とSQL Serverなど使うものかと思いながら、それまで書いたコードを破棄して、手慣れたXMLを使ってコードを書き始めることになる。

INDEX
	［完全版］究極のC#プログラミング
	Chapter17　LINQ to SQL
	1．17.1 効率的に列挙可能にするという問題
	2．17.2 SQL Serverのワナ
	3．17.3 LINQ to SQLという突破口
	4．17.4 LINQ to SQLのサンプル
	5．17.5 LINQ to SQLとメソッド構文
	6．17.6 LINQ to SQLのまとめ／練習問題

　

「［完全版］究極のC#プログラミング」

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