skillup

技術ブログ

Database

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

投稿日:

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

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

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

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

ということですね。

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

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

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

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

ぐるぐる系

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

長所

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

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

実行計画が安定する

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

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

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

短所

遅い

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

並列分散がやりにくい

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

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

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

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

ガツン系

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

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

長所

比較的高速

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

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

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

短所

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

-Database
-

執筆者:


comment

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

関連記事

no image

dbUnitの使い方

えーJavaで有名なテストツールDBUnitについて。 DbUtilではありませんので間違えないように。(私は最初間違えました・・・) まだ全然使い込んでるわけではありませんがどんなことができるかとい …

no image

外部結合について 行列変換

今回から外部結合について学習します。 これはCASE式でもやった集合の考え方が大事になってきます。 例えば下記のようなテーブルCoursesとがあるとします。 name | course &#8212 …

no image

checkboxでの値の管理

formにてcheckboxの値を一つのカラムにいれて管理する機会があったのですが、これ入力更新出会っても検索であっても処理がなかなか厄介です。特に検索の時ですね・・・ 要するに値の候補が1,2,3, …

no image

ajaxのasync:falseと複数DBのjoinに関して

本日も小ネタ集です。 Contents1 ajax:false2 複数DBでのJOIN ajax:false ajaxは非同期処理が基本ですが、async:falseとすると同期処理になります。 ただ …

no image

mysqlデータのCSV出力

ガチンコ塾のブログでもかいたのですが、行動力が大切だなーと思う今日この頃。 社長が熟練のJavaエンジニアで基本的に聞けば、基本的に解決することが多いのですが、外部の勉強会などにも出て情報収集の必要性 …

アーカイブ