ＳＱＬ

（１）ＳＱＬは簡単な方が良い

複雑なＳＱＬを１個書くよりも、単純はＳＱＬを組み合わせた方が、テストも簡単に済みます。例えば、ＭＳ_ACCESSでは、クエリーがＳＱＬに相当します。ひとつのクエリーにたくさんのテーブルを含めて、複雑に関係付けると、テストも大変です。複雑なクエリーを１個作るのではなく、単純なクエリーに分割して作成し、それをひとつのクエリーにまとめるほうが、テストも簡単に済みます。

ＯＲＡＣＬＥの場合のビューも同様です。大きくて複雑なビューをひとつ作るよりも、複数の単純なビューに分割して作成し、それらをひとつのビューにまとめた方がテストがラクです。

（２）クエリーやビューの階層は標準２階層、最大３階層まで

前項では、クエリーやビューは分割して作成してから、ひとつにまとめた方が良いと書きました。しかし、分割し過ぎてクエリーやビューの階層が深くなりますと、こんどは、どのクエリーがどのクエリーを参照しているのか分からなくなり、保守性が悪くなってしまいます。クエリーやビューの階層は、２階層を標準とし、最大３階層に止めておいた方が良いでしょう。

余談ですが、ＯＲＡＣＬＥのシステムテーブルには、（ＭＲＰでよく使われる）部品表の構成レコードのように、ビュー同士の親子関係が登録されているものがあります。このシステムテーブルを利用すると、ビュー同士の関係や階層を管理することができます。

 

（３）クエリー（やビュー）を構成するクエリー（やビュー、テーブル）は２個から３個まで

複数のクエリーやビューを組み合わせて新たなクエリーを作成することができます。構成するクエリーやビュー、テーブルの数が多いほど、テストもやり難くなり、ミスも多くなります。一個のクエリーで、まとまった処理をやろうとすると、クエリー自体も複雑になり、文法エラーも起こしやすいし、テストもメンドウです。私は、やむなく３０個のテーブルを組み合わせたビューを作成したことがありますが、コーディングやテストにかなり手間がかかりました。

（４）ＳＱＬを実行して結果が得られても、それが正しいとは限らない

若手ＳＥは、苦労して作成したＳＱＬを実行して結果が得られると、それが正しいものだと思い込んでしまう傾向があるようです。しかし、結果が得られても、それが自分の意図した結果でないことが良くあります。ＳＱＬもプログラム言語ですから、結果が出たからといって油断しないで、キチンとテストをしてＳＱＬの動作を確認してください。ＳＱＬは、一種の集合演算命令ですから、ＶｉｓｕａｌＢａｓｉｃやＣＯＢＯＬなどの手続き型言語に慣れたＳＥは、勝手が違うせいか良く勘違いをするようです。

（５）複雑なＳＱＬは簡単なＳＱＬから段階的に作れ！

複雑なＳＱＬ文を書かなければいけない場合であっても、いきなり複雑なものを書こうとするとうまくいきません。文法エラーになるし、文法エラーが解消しても、思ったように動作せず、原因を調べるのに時間がかかったりします。基本的なＳＱＬを最初に書き、動作を確認しながら、それに肉付けをし、段階的に目的の機能を持ったＳＱＬを作成するのがよいと思います。そうすれば、作業途中で文法エラーが出たとしても、追加変更した部分が原因ですので、ミスの発見も早いです。