連載:[完全版]究極のC#プログラミング

Chapter17 LINQ to SQL

川俣 晶
2010/04/14

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#プログラミング」


Insider.NET フォーラム 新着記事
  • 第2回 簡潔なコーディングのために (2017/7/26)
     ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている
  • 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
     Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう
  • 第1回 明瞭なコーディングのために (2017/7/19)
     C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える
  • Presentation Translator (2017/7/18)
     Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

注目のテーマ

Insider.NET 記事ランキング

本日 月間