skillup

技術ブログ

Database

SQL基礎 手続き型言語と集合思考の言語

投稿日:

どんな仕事でもそうだと思いますが、長年惰性で使っていると日常の作業はなんとかできてるけど、実は深く理解していない&効率のいいやり方を知らない、ということが結構あります。

私の場合、ちょっと前にCSSを勉強してそれに気づきましたが、SQLでも同じことがいえますね。

根本的なことがわかっていなくて、「SQL実践入門」やSoftwareDesignの連載で書いてありますが、

「SQLは集合指向の言語である」

ということですね。

例えばある帳票への出力の際に、計算値(合計や加減乗除)を出力する場合、1行ごとにループさせた処理をすると非常に重くなります。

このような場合、逆にある程度複雑であってもSQLである程度集計したような計算をしたほうが圧倒的にパフォーマンスが良くなります。

「SQL実践入門」では前者のようなループを過度に使ったSQLのことをぐるぐる系、後者のような集計をしたSQLをガツン系といっています。

ぐるぐる系とガツン系の特徴を書いておきます。

ぐるぐる系

比較的単純なSQLをループを繰り返して複数発生させる

長所

シンプルで書きやすい
実行時間の算出が比較的容易

ここのプログラムが単純なため、実行数をかけることで時間をだいたい算出できる

実行計画が安定する

変動リスクが少なくパフォーマンスの安定性を確保できる。

トランザクション制御が比較的用意

途中までで処理を走らせて途中で中断した場合、リスタートなどをすることができる

短所

遅い

一般的にデータ量に比例する。処理時間そのものに加え、1回1回の処理でオーバーヘッド(SQLを解釈して評価する)時間が比例してかかる

並列分散がやりにくい

リソースを分割した並列処理による恩恵を受けられない

データベースの進化による恩恵を受けられない

処理が単純すぎるため、改善の余地があまりなく、バージョンアップしてもスピードアップの恩恵を受けられない

一般論でいうとこのタイプなSQLは避けるべき。

ガツン系

集計処理が可能な場合は、ループを回すのではなく一括で処理を書いてしまうSQL

長所・短所はほぼぐるぐる系の裏返し

長所

比較的高速

オーバーヘッドの時間がないため、データ量が増えても、処理時間が正比例にはならない

チューニングネタが数多くある

ぐるぐる系に比べると早くするポイントが非常におおい。

短所

書くのが比較的難しい
見積もり時間の算出がやや難しい

-Database
-

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

no image

HAVING句がらみの計算式

「達人に学ぶSQL徹底指南書」読んでますが、かなり難しいものがでてきましたね。 テーブルは前回のものと同じ以下のものを使います。 name | income ————+——– サンプソン | 4000 …

no image

データクレンジング

リレーショナルデータベースでデータを管理する前に、しなくてはいけないことはデータをデータベースに登録できる形に整形することです。 このことをデータクレンジングといいます。 これを行わずに何も考えずにデ …

no image

cakeでのトランザクション、コミット、ロールバック

cakePHP(2.X系)でのトランザクション、コミット、ロールバックについて。 cakePHPでトランザクションを書ける場合、Model内に [crayon-6606dcf1960b38234943 …

no image

JPQLでの算術関数

複雑なJPQLを書いていると、通常のレコードの取り出しだけではなく、合計(SUM)や算出(COUNT)などのいわゆる算術関数を使うことが一般的です。 JPQLでもこれらを通常通り扱うことができます。 …

no image

外部結合 応用編2

引き続き結合についてです。 Contents1 1対Nの結合に関して2 完全外部結合3 差集合(class_aだけに存在するものとclass_bだけに存在するもの)3.1 class_aのみ3.2 c …

アーカイブ