Slashcolon /:

デスマ入り目前のプロジェクトに社内派遣されてました その中で見たのが、以下のようなSQL。

SELECT
 NVL((SELECT C_1 FROM T_1 WHERE J_1 = /*NoId*/), ' ') AS A_1,
 DECODE((SELECT C_2 FROM T_1 WHERE J_1 = /*NoId*/), '1', 'true', '2', 'false', 'false') AS A_2
 ……同じようなものの繰り返し……
 FROM DUAL

とにかく長い…実際にはWHERE句ももっと長いし名前も長い、SELECT文が画面一杯続いた後…FROM DUAL なんじゃそのテーブルは、データベースを一からお勉強したことのないわたしには結構衝撃のDUALテーブル。はい、DUALも知らないボクが通りますよぉ

Oracle屋さんには、入門Oracleなどの本でお馴染みのテーブルらしいのですが…そんなの知らないわたしはDUALってテーブル何状態。要するにダミーテーブルみたいなものらしい。まぁ、すぐにググって…ふ～んって感じだったわけですが…使う場面なの

しかし、DUALの扱いというかSELECTの構文だけでも有名どころのデータベースで結構違いがあるんですね～DUALはOracle, MySQLにはあるけどPostgreSQLにはないとか、FROM句を省略できたりできなかったりとか。

で、DUALテーブルをググってる途中で見つけたSIGSEGV – MySQLのSQLチューニング（IN 演算子）の結果面白いですね～まぁ、この辺りになるとわたしには魔術の世界ですね。MySQLのIN演算子って遅いのか とか色々。

上記ページに以下のように書かれているわけですが…以下斜体部引用。

同じ結果なのに歴然とパフォーマンスが変わるところがSQLチューニングの醍醐味ですね。

この感覚非常によくわかるんですが…わたしの場合は、その辺りが許せなくてSQL嫌いのデータベース嫌いの一因になってたりします

基礎からのMySQL [基礎からのシリーズ] (プログラマの種シリーズ) 西沢 夢路 by G-Tools

このブログで関連すると思われる他の投稿

• PostgreSQL 8.3登場…これは良いかも
• SYS_CONNECT_BY_PATH…でハマル
• う～ん、良い解法が思いつかない
• 嫌いな一因発見…でもSQLは嫌いですぅ
• お仕事…Busyモード

Comments(0)       

TrackBack URL :