December 5, 2007.

クリエイタ連鎖

好きなクリエイタについて調べていると、その人が別の好きなクリエイタと親交があったりする。例えば、造形作家のページを眺めていたら、のすさんののんちゃんやラレコさんのクワガタツマミややわらか戦車が造詣対象になっていたりする。小説家や漫画家にはその関係が多くて、もう、ここではいちいちあげられない。

今日も、大好きな西洋鍛冶師ののブログを見ていたら、タチコマロボットで有名な(いや、普通はマノイとかの方をあげるだろう)人がブログにコメントをくれて...というような話が書いてあってびっくり。本当に多ジャンルの猛者たちが見えない網でつながっている。baristaはそういう連鎖を遠巻きに眺めるのがとても好きなのだ。baristaは完全な無神論者なのだが、こんな時には「みて、この美しいつながりを」とスピノザの神に自慢したくなる。描いた絵を母に自慢する子供のように。

そんなわけで、リンクページに上記の人々のページへのリンクをガッツリ追加予定。いつか自分が美しい網の一部に....加わりたいという意識を持たないようにしましょう。まずは美しい糸を紡ぐこと。

【実行プラン】

最近SQL Serverに付属のManagement Studio Expressを用いた「実行プラン」によるSQL速度の測定に凝っている。長年この業界にいるのに今更かよと突っ込まれそうだが。

試してみてまず驚いたのは、複数のテーブルを結合してからWhereで絞っても、Whereで絞ったサブクエリを結合してもコストが同じだったこと。実行プランの図の構造も同じ。恐らくSQLの最適化がDB内で行なわれるのだろう。他のDBでどうなるのか比較してみたいところ。また、上記と同様にinner joinの条件でレコードを絞っても、join後のwhereで絞っても結果は同じだった。

さらに意外だったのはleft joinとinner join。innerで問題ないデータを用いて比較した場合、両者のコストはほぼ同じだった。leftの方がほんの少しだけコストが高い。しかし思っていたほどの差が出なかった(1/1000程度の差だった)。しかし全く結合対象が無いデータで試したところ、1/20程の差がついた。結合対象が無いときのleftが遅いという話はこういうことかと納得。どっちにしてもleftとinnerは目的が違い、leftをinnerに置き換える事はできないので、選択肢の決定要因は速度ではないのだが、innerで済む箇所も全てleftで書くテヌキストもいるので安心はできない。

とりあえず、面白いおもちゃを手に入れたので、遅いSQLと速いSQLを調べて楽しもうと思う。いや、スキルアップに努めようと思う。本音は無論、前者である。

Copyright 2007 barista. All rights reserved.