Accessでクエリー地獄を作ってしまう

 MS Accessはとても便利なアプリケーションで、クエリーという機能がその便利さのけっこう大きな部分を占めます。

「テーブル」と呼ばれる表にデータを蓄積させておいて、それを、あらかじめ決めたルールでフィルタし、ソートし、グループ化して値を合計し、他のテーブルと結合し…　という感じに自由に加工して表示させるという機能がクエリーです。この加工ルールをレシピとして保存しておき、それを必要なときに呼び出すと、表示したときの見た目はテーブルとほとんど変わらないのに、テーブルに入っている実際のデータをいつでも反映したものが得られます。すこし使い慣れてみると、これだけでもきわめて便利なものだと分かります。

（クエリーには追加クエリーや削除クエリーという別機能のものもありますが、今は省略。）

ちょっとだけ加工のルールを変化させたクエリーが欲しいときは、一般的には、いったんクエリー定義のコピーをつくって、それに調整を加えて新しい名前をつける、とするのをよく見ます。クエリーの定義を増やさずにうまくやる方法もあるのですが、そういうのはすこしコツがいるので、ついついたくさんのクエリーを作りすぎるというのは、Accessにおける「あるある」でしょう。

「テーブルとの結合」というデータ加工の方法をさきに挙げましたが、これは、Excelでいう「VLOOKUP」をご存じならすぐ分かるものです。例で言えば、あるテーブルには商品コードが入っていて、別のテーブルには商品コードと商品名が入っているとします。このときに、もとのテーブルの内容に、対応する商品名を付け加えて表示させたいときに力を発揮するものです。この場合、ひとつのクエリーが、複数のテーブルに依存したものになります。

クエリーの表示結果はテーブルと変わりない見た目だ、と言いましたが、そのおかげで、あるクエリーの結果を使って他のクエリーを作る、ということさえ可能です。このために、クエリーを材料にした別のクエリー、というものも増殖しがちになります。

クエリーをもとにして別のクエリーをつくり、それはまた別のクエリーの材料になり…

かくして、最終的にできあがるかもしれないクエリーは、とてもたくさんのテーブルがクモの巣のように絡みついた、恐るべき複雑さを持ったクエリーになる、というのが、意外と冗談でなく、起こることがあるのです。プロジェクトの中にリストアップされたクエリー定義の数は数十個にもなり、どれがどういう表示ルールだったのか分からない。整理しようと思って、明らかに使っていないようだ、と思われるクエリー定義を削除してみると、それは他のクエリーの一部に使われていたものだったので、システムに故障が発生してしまう。かくして、今存在するクエリーは一切変更してはならない、必要があるときは全く新しいクエリー定義を作って対応すること、というルールが生まれたりします。この現象をクエリー地獄と呼ぶ人がいるとかいないとか。

これにうまく対処するための方法はいろいろあるのですが、何しろ、一定の慣れが必要になることは間違いありません。このクエリー地獄を味わってみて、「どうすればこうならずに済んだのだろう」と反省してみる、というのは、これはこれで得がたい経験なので、一度はこういう経験を経るというのは、案外、Accessに熟練するための必須プロセスと言えるのかもしれません。