職業プログラマの休日出勤

職業プログラマによる日曜自宅プログラミングや思考実験の成果たち。リアル休日出勤が発生すると更新が滞りがちになる。記事の内容は個人の意見であり、所属している(いた)組織の意見ではない。

SQLWorld★大阪 #19 に参加しました

日常会話をSQLとResultSetで取り交わす人達…ではなくて、仕事や趣味などでSQLを使う人達の集まりである、SQLWorldに参加してきました。
SQLWorld★大阪#19
今回は「初心者向け」だったそうですが、中には難しい問題も混ざっていたような…?(笑)

集まりの概要

僕は今回が初めての参加だったので普段がどうなのかわかりませんが、大体こんな感じでした。

  • 主宰の おださん が出される問題にSQLで回答する
  • 提出した答案を評価しあったり、など
  • テストデータやSQL文の実行環境や答案の共有システムは Azure 上に構築されている(Webブラウザで操作) → SQL Serverの利用
  • 参加者は9名。普段からSQLをバリバリ書いているのは4名くらい?(たぶん)

問題を解くのに必要だった知識

出題内容全てに「まともな」回答をつけるには、以下のような知識が必要でした。

  • 普通のselect文の構文
  • 集計関数(count, max, min, avg, stdev, など)とGROUP BY
  • サブクエリ
  • 結合
  • window関数
  • case句

window関数やcase句は使いこなせなくてもjoinとサブクエリを駆使すれば解ける問題構成でしたが、

という雰囲気があったのも事実。window関数は普段使うことがあまり無いので、構文を思い出せずにググってしまいました。

失敗したこと

とりあえず問題にはすべて正常に動作する答案を提出することができましたが、会が終わろうとするときに一つ重要な誤りを犯していることに気が付きました。
テストデータのテーブルに「年月」を表す列があったのですが、その定義が char(6)と文字列型であることに気付かずに、where句などの条件では整数値で表された年月と比較してしまっていたのです(例:201312のような、シングルクォートで囲われていない表現)。SQL実行時は暗黙の型変換が走るので(通常は)期待通りの動作をするのですが、良くはないですね。この勝負、僕の負けです。

次回

次回(#20)は、来年の1月25日(土)です。楽しみにしています。その次は2月18日(火)だそうです(これは仮なのかもしれない)。