はじめに
流行りすたりの激しいソフトウェア開発の世界でも、昔からほとんど変わらっていないものがいくつかあります。その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ドルもらえるという制度があれば今ごろ私は大金持ちのはずですが...）。
データベースの設計は、ビジネスルールをまったく無視して行えるものではありません。データを実際に使うユーザーの話を聞き、彼らにうるさくつきまとって、各フィールドの必要なサイズ、各フィールドに適用されるルール、各フィールドのデータ型、各フィールドを更新できる人、その他諸々の情報を確実に入手することが何にもまして大切です。これを怠ると、後から作業のやり直しが発生して無駄なコストがかかります。その後おそらく、「見た目はいいんだけどね...」という言葉を聞きたくなくなるでしょう。
