e-learning、オラクル研修、LMS(学習管理システム)のiStudy

e-learning、オラクル研修、LMS(学習管理システム)のiStudy

第82回 コラム「複雑で長すぎるSELECT文」

2013.12.26

こんにちは。インストラクターの蓑島です。
早いもので今年最後のメルマガです。

今回は技術的な話ではなく、簡単なコラムです。題して「複雑で長すぎるSELECT文」。

皆さんは、複雑で長いSELECT文を書いて問題になっていませんか? 

SELECT文はSQL文のなかでも特に機能が充実しており、ユーザの複雑な問い合わせ要件に対応できるように豊富な文法が用意されています。
したがって文法的に正しければきちんと問い合わせの結果を返してくれますが、しかし、あまりにも、一つのSELECT文に多くの要件を詰め込んで複雑にしてしまうと、後から問い合わせ要件の修正があった場合に、適切に対応できなかったり、データ量が増えるにしたがって、パフォーマンスが悪化する問題に直面することがよくあります。複雑で長いSELECT文は一般にチューニングもしずらいものです。

このような状況は、データベース設計が適切ではないケース、パフォーマンスを意識しないプログラマーが文法的に正しければよいという観点からコーディングを行うケース、さらに、安易に他のプログラムからSELECT文をコピペして、コーディングを行うケースなど、大きく3つのケースがあるのではないかと思います。

まず、データベース設計が適切ではないケースです。
データベース設計が適切でないと、例えば表と表の関連づけも明確にされていないことが多いです。したがって、主キーと外部キーの一致といった単純な結合条件とならないことが多く、問い合わせが複雑になりがちです。

次に、パフォーマンスを意識しないプログラマーのケースです。
SELECT文というのは、プログラム言語のように手順を記述しているわけではないので、パフォーマンスを意識しずらい言語といえるかもしれません。
したがって、文法的に正しいかどうかだけが関心事となり、複雑で長いSELECT文を文法的に正しく組み立てるのが腕の見せ所のように考えてしまうことがあるのではないでしょうか?

次に、安易に他のプログラムからのコピペのケースです。
例えば、SELECT文をゼロから組み立てることをせずに他のプログラムから、バグのないSELECT文をコピーして、それを副問い合わせの形で組み込んでSELECT文を組み立てることがよくあるのではないでしょうか?
そのような副問い合わせをFROM句に記述して、表のように見立てて結合したり、問い合わせの条件に使ったりしてると、確かに正しい結果を返す問い合わせかもしれませんが、過度に複雑な問い合わせとなります。

以上、3つほど、過度に複雑なSELECT文が記述されるケースを述べてきました。
そして過度に複雑なSELECT文はなるべく避けた方が無難です。パフォーマンスなどの問題が起きた時に過度に複雑なSELECT文では適切な対応が難しくなります。また、修正も容易ではありません。

複雑で長いSELECT文となるときは、PL/SQL言語を使って、単純なSELECT文だけを使って要件を満たすように手順を設計すれば、パフォーマンスなどの問題が発生しにくくなります。

例えばPL/SQL言語はSQL言語単独と違って処理手順をコーディングします。
したがって、一つの大きなSELECT文で処理を完結するのではなく、一つ一つの手順に分解してその手順を満たすSELECT文を変数を介在させながら実行して行けば、一つ一つのSELECT文は一般に単純なものとなります。
もちろん、SELECT文の数が若干増えますが、パフォーマンスの悪い一つの大きなSELECT文を実行して後々問題となるよりは、分かりやすさの面でも、パフォーマンスの面でも、メリットがあるケースが多いと思います。

そんなことを心に留めておきながらPL/SQL言語を利用して単純なSELECT文を使うことを心がけてみてください。

それでは今回はここまでといたします。
皆さん、よいお年をお迎えください。

先頭へ戻る