古い要約照会の技法を捨てる
本稿では要約照会を作成する際に従来から使っていた古い 2 つの方法と、それより優れた新しい方法を 2 つご紹介します。
まず、照会するデータベースが必要です。次のような顧客の表があります。
次のような出荷の表があります。
では、これらの売上を顧客ごとに合計するよう求められたとします。読者のようなプロならば簡単でしょう？
そうですね、しかしリクエスターは顧客それぞれの名前を含めるよう要求しています。顧客名は売上ファイルにはないため、顧客表をクエリーに追加する必要があります。
これは次のようにしてできます。
これで正しい結果が得られますが、そのためには顧客名を要約列として含める必要があります。(つまり、GROUP BY 節に顧客名を追加する必要があるということです。)この不要なグループ化列 (フィールド) を追加するのは余分な作業になり、クエリーが大量のデータを実行しているときに実行時間が長くなる可能性があります。
代わりに、これは次のようにしてできます。
顧客名は要約列でなくなりますが、SELECT の MAX 関数に注目してください。顧客名は機能的に顧客 ID に依存しているため、多数の同一の値を最大限検索するのに時間が費やされます。それは余計な作業であり、誤解を招くおそれもあります。同じカスタマー番号に対する売上について NAME の値は異なる可能性があることを意味しているためです。
SQL が今ほどパワフルでなかった何年も前に、そうした手段を使用したことがありますが、今は使用しておらず、お勧めもしません。そうしないで、あたかも表またはビューのように要約照会にアクセスします。
顧客名は要約フィールドではなく、MAX 関数はありません。まず内部照会が実行され、要約の数字を構築します。次に、その結果セットをカスタマー・マスター・テーブルに結合して、顧客名を取得します。
一般的な表式を使用することもできます。
いまだに最初の 2 つのような照会を目にします。昔からの習慣はなかなか治らないのでしょう。
私は、皆さんにより新しい技法を使用するよう勧めているだけでなく、こうした技法を使用している古い照会を作成し直すことも検討するようお勧めします。
古い技法を新しい技法に置き換えるのは取るに足らないことのように見えますが、ささいなことの積み重ねが大きな違いを生むことがあります。ジム・ローン曰く「成功とは、普通のことを並外れて上手くやることだ。」ということです。
