skillup

技術ブログ

Database

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

投稿日:

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

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

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

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

ということですね。

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

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

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

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

ぐるぐる系

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

長所

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

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

実行計画が安定する

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

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

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

短所

遅い

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

並列分散がやりにくい

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

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

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

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

ガツン系

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

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

長所

比較的高速

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

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

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

短所

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

-Database
-

執筆者:


comment

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

関連記事

no image

NOT EXISTSの利用2

今回もNOT EXISTSの利用です。 前回の問題にプラスアルファし、列が一緒でないと連続でも意味ない仕様にします。 例えば下記のようなテーブルがあるとします。 seat | row_id | sta …

no image

JPAでのリレーション(アノテーション使用)

JPAでリレーションを管理するとき、最初はアノテーションでやろうとしたんですが、結局やり方がわからずコンストラクタ式をかいて対処してました。 JPAでのリレーションに関して 外部キー制約があるやり方は …

no image

データベースによるテストデータ作成

テスト環境を作る際に、テストデータを作るのが面倒・・・なんかライブラリでもないかな・・と思っていたんですが、MySQLでいろいろと簡単にできます。 数字 [crayon-61a34298068df21 …

no image

CakePHPでの数字カンマ区切り&PHP&MySQL曜日の出力

今回は主に時間やお金の表示など、出力に関するネタです。 Contents1 Cakeでのカンマ区切り1.1 単純なカンマ区切り 例1,0001.2 \をつけるケース 例 \1,0001.3 円をつける …

no image

第二、第三の正規化&ER図&Check制約

前回第一正規化を話したので、第二、第三に進んでいきます。 Contents1 第二正規化とは?2 第三正規化とは?3 正規化のメリット4 ER図5 本日のSQLネタ Check制約 第二正規化とは? …