skillup

技術ブログ

Database

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

投稿日:

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

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

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

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

ということですね。

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

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

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

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

ぐるぐる系

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

長所

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

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

実行計画が安定する

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

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

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

短所

遅い

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

並列分散がやりにくい

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

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

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

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

ガツン系

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

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

長所

比較的高速

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

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

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

短所

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

-Database
-

執筆者:


comment

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

関連記事

no image

自己結合に関して

以前もこのエントリーで学習しましたが、SQLの結合では自己結合という考え方があります。 下記のようなテーブルProductsがあるとします。 name | price ——&# …

no image

cakePHPでのマイグレーション

開発を続けているとデータベースのカラムの構造が変更するってことはしょっちゅうですが、管理がいい加減だとメンバー間でテーブルの構造が変わっていたり、本番と開発で違ってくるなどのトラブルが続出します。 そ …

no image

mavenのリモートリポジトリについて

JPAでO/Rマッパーに慣れてからというもの通常のSQLをごりごり書くのが億劫になってきました。 億劫というかいろいろとリスクがありますね。 問題点としてはコンパイルするときにエラーが検知できなかった …

no image

日付がらみの処理に関して(MySQL&Java)

MySQL触りだして3年ぐらいたつんですがいまだに整理できないことが多いです。(特に日付がらみ) ちょっとJavaのネタと合わせて整理しておこうかなーと思います。 Contents1 MySQLの日付 …

no image

MySQL小ネタ テーブル単位のリストア・SQLの小ネタ(バックスラッシュの検索)

MySQLのちょい小ネタ。 Contents1 テーブル単位でバックアップ&リストア2 バックスラッシュの入ったSQLについて テーブル単位でバックアップ&リストア 1 通常のdump(データベース単 …