DB構築時の10大ミス - japan.internet.com デベロッパー

はじめに

　流行りすたりの激しいソフトウェア開発の世界でも、昔からほとんど変わっていないものがいくつかあります。その1つがデータベースの運用の仕方です。多くの開発者はAJAX Webインターフェイスや最新の目を見張るようなWindowsユーザーインターフェイスを積極的に採り入れていると思いますが、その陰で、今もなお10年前と同じようにデータベースとのデータのやりとりに難儀しているのではないでしょうか。さらに驚くことに、開発者は古き良きWindows 95以前の時代と同じようなミスを未だに繰り返しています。もしかしたら、我々はデータベースの使い方をなんとなく覚えただけで、データベースの何たるかを本当には理解していないのではないでしょうか。ともかく、私がこれまで再三目にしてきたミス、その中で特に重要と思われるものを私なりに列挙してみました。

データベースの選択を誤っていないか

　データベースは素性がどれも同じというわけではないので、データベースを扱うときは目的にかなったデータベースを選ぶことが大切です。SQL Serverで処理すれば朝飯前なのにAccessデータベースで無理矢理巨大なデータセットを処理しようとする、あるいは高価なSQL Serverを導入したのに扱うデータはたった数百行しかない――そんな例を私は幾度となく目にしてきました。

　大まかに言って、今日利用できるデータベース製品は3つの階層に分類できます。第一は、小規模な業務に適したデスクトップおよび組み込みタイプのデータベースです。第二は、数ギガバイトのデータを扱うのに向いている「エクスプレス」版のデータベースで、これが市場の中心を占めます。第三は、SQL Server、Oracle、DB2のような企業向けの本格的なデータベースで、データベースに投入できるデータであれば、たいていの処理をこなすことができます。何をするにせよ、まずは将来のストレージのデータ量を現実的に見積もり、使用するストレージ製品を選ぶ必要があります。

採用するデータベースの種類が多すぎないか

　ODBC、JDBC、OLE DBといったAPIによって、データベースの独立性という概念が広まってきました。これはさまざまな種類のデータベースをデータストレージとして接続できるようにアプリケーションコードを記述するというアイデアですが、少々問題もはらんでいます。開発チームがデータベースの独立性の罠にはまり、すべてのSQLステートメントをあらゆるデータベースの最小公倍数的な表現形式に変換するレイヤを開発しようなどと考えてしまうことがあるからです。これは同時に、いずれかのデータベースで提供される高度な機能を切り捨てることを意味します。

　彼らの主張としては、いつか、どこかの顧客がOracleやDB2、あるいはFoxProなどに切り替えたいと思うかもしれないので、今のうちに用意しておくべきだということなのでしょう。しかし、あまり実際的ではありません。新しい製品に取り組むときは、ストレージエンジンを入念に選び、それに合わせてコードを書くべきです。まともな製品を選んでいる限り、ユーザーはこちらが指定したデータベースをインストールするはずですし、そうすれば、本当にやってくるかどうかもわからない「いつか」のために無駄な労力を割かなくて済みます。

対象データを本当に理解しているか

　ほとんどの顧客番号は6桁だが一部は7桁であるとか、学生の受講登録時には本人の意思により社会保障番号の登録を行わない場合があるので当該フィールドをNULL受け付け可にする必要があるなど、データにはさまざまなルールがあります（このようなルールを見つけるたびに1ドルもらえるという制度があれば今ごろ私は大金持ちのはずですが...）。

　データベースの設計は、ビジネスルールをまったく無視して行えるものではありません。データを実際に使うユーザーの話を聞き、彼らにうるさくつきまとって、各フィールドの必要なサイズ、各フィールドに適用されるルール、各フィールドのデータ型、各フィールドを更新できる人、その他諸々の情報を確実に入手することが何にもまして大切です。これを怠ると、後から作業のやり直しが発生して無駄なコストがかかります。その後おそらく、「見た目はいいんだけどね...」という言葉を聞きたくなくなるでしょう。

Excelのようなものと単純に考えていないか

　世の中の人々は（特に小さな会社の経営者などは）、開発者なら誰でもデータベースのセットアップの仕方を知っているはずだと思っているようです。正直、そのように言われると私などは言葉を濁してしまいます。C#プログラムの書き方やWebサービスのセットアップの方法も知らない開発者が、データベースのプロと呼ばれているのが現状だからです。実際のところ、正規化という用語など聞いたことないとか、各種の正規形について理解する必要などないという人々によって設計されたデータベースがごまんとあります。あらゆるものを1つの巨大なテーブルに押し込めて、結果的にひどく変則的な更新処理をしたりパフォーマンス的な問題が生じたりしているケースを私は数知れず見てきました。

　もし、あなた自身がこのような状況に陥っていてお手上げ状態なら、教育訓練を要求するか、新たに職探しを始めるべきです。データベースをうまく設計するためには、試行錯誤ではなく、学習によって得られる何かが必要なのです。

第3正規形は究極の目標にあらず

　他方、半端な知識が危険になることもあります。私は過去に、「あらゆるものを参照テーブルに入れるべき」と主張する原理主義的な開発者によってとことん正規化されたデータベースを見たことがあります。今でもよく覚えているのは、「yes」と「no」をtblAnswersテーブルに入れ、それらを他のテーブルから外部キーAnswerIDで参照できるようにするというものでした。

　確かに正規化のルールを知っておくことは大切ですが、正規化をどこまで進めるか、またどのような場面で性能向上のための非正規化を採用するかといった判断のスキルを身に付けることも必要です。

アプリケーションロジックを安易に隠蔽していないか

　ストアドプロシージャやトリガは素晴らしいものです。これらの仕組みは、同じデータベースを複数のクライアントに使わせるときに、データ処理の一貫性を保つために役立ちます。しかしその反面、ストアドプロシージャやトリガは不愉快なブラックボックスになる危険もはらんでいます。アプリケーションロジックを隠蔽し、Web開発者やシッククライアント開発者の目から隠してしまうため、適切な評価やレビューが行われない状況になるのです。

　データベースコードが、アプリケーションの他の部分で要求されている設計、テスト、およびコードレビューの標準に従っていないという事態はよく起こります。データベースにコードを埋め込もうとするときは、それが本当にそこに属すべきものなのか、少し時間をとって考えるようにしてください。

バックアップを必要とするのは誰か

　バックアップを必要とするのは誰なのかを考えてみましょう。それは、データベースの管理者であり、開発者です。データをデータベースに格納するのは、それだけの重要性があるからです。しかし、「誰もそこまで手がまわらない」という理由でバックアップをおろそかにしていると、ハードウェア障害、ハッカー、あるいは単純ミスのせいでデータベースが破壊されたときに、貴重なデータが永久に失われることになります。バックアップの周期、種類、オフサイトでのバックアップの頻度といったバックアップ計画を、開発サイクルの最後ではなく、最初の段階で策定しておく必要があります。

バージョン管理の必要性

　バックアップと言えば、データの変更だけでなく、データベーススキーマの変更にも注目し、スキーマの変更を追跡して任意の時点のデータベースを再現できるようにしなければなりません。ソフトウェア開発の仕事を本格的に進めようとするのであれば、バージョン管理の対象をデータベースの設計にまで広げる必要があります。対応するデータベースも再現できなければ、バージョン0.784.5のソフトウェアを復元してバグを検証するといった作業はうまくいきません。開発者が改訂履歴を残さずにストアドプロシージャの作成やテーブル構造の微調整を重ねていくと、問題に突き当たることになります。

ツールの使用

　最近のデータベースは、データを出し入れする仕組みを提供するだけでなく、データを管理するためのさまざまなツールも提供しています。たとえばSQL Serverには、クエリの実行プランを確認するための機能や、クエリの効率化と実際のサーバー負荷の軽減に役立つインデックスを教えてくれるウィザードが用意されています。私はこれらのツールをクライアントデータベースで用いて高速化に成功しましたが（CPU使用率を半分に軽減）、実際のところ、その使い方を理解するためにコンサルタントを呼ぶ必要はありませんでした。

　データベース製品の価格には付属ツールの分も含まれているのですから、どんなツールやユーティリティが付属していて、どんなことができるのかを調べてみましょう。

いつでも同じやり方が通ると思うな

　アプリケーションのデータをなんでもかんでもデータベースに入れようとする傾向がときどき見られます。私が過去に見たいくつかのアプリケーションは、メタデータに基づくユーザーインターフェイスを実装していて、そのメタデータとユーザープリファレンスを、ビジネスデータと同じデータベースに格納していました。このようなやり方は、話を複雑にし、パフォーマンスを低下させるだけです。

　データの性質によっては、ネットワーク上のクライアント-サーバーデータベースではなく、ローカルファイル内に配置するべきです。データを格納するときは、候補となる場所（データベース、レジストリ、プレインテキストファイル、XMLファイル、その他）を評価して、そのデータにふさわしい場所を選ぶ必要があります。接続文字列が手っ取り早く使えるという理由だけで機械的にデータベースにデータを押し込んではなりません。最近では、リレーショナルデータベースの濫用よりもXMLファイルの濫用が目につくようになりましたが、この原則は変わりません。