tsucchi’s diary(元はてなダイアリー)

はてなダイアリー(d.hatena.ne.jp/tsucchi1022)から移行したものです

技術者なら SQL は必須だけど

うーん、どうにも納得できないなぁ。

ベンチャー社長で技術者で: 上流の技術者はSQLを高いレベルで習得すべき

そこで、以前からの蒸し返しですが、「上流の技術者はSQLを高いレベルで習得すべき」と改めて一度、声を大にして言いたい。

SQL は確かに上流下流に関わらず知ってなきゃダメだし、インチキ臭い「上流」コンサルや「上流」技術者はオイラも嫌いだけどね。

でも何でもかんでも SQL に解決策を求めるのはちょっと違うと思うなぁ。

もしあなたが持っている唯一の道具が金づちなら、あなたは全ての問題を釘として見るようになる。- IT業界の裏話

アブラハム・マズローの至言であるこの言葉は誰にでも当てはまる話だと思いますが、IT業界に当てはまると次のようになりますかね。

とまあこんな感じで、SQL の上級(≠上流)技術者だと、どうしても何でも SQL で書きたくなっちゃうんだろうなぁ。

たとえば、ループで処理するやり方と SQL で処理するやり方で、10倍のパフォーマンスの差があるとして、でもループでも 1秒ならそんなに気にしなくてもいい(ループでもいい)。ループで1時間なら、SQL でも6分、SQL でもリアルタイム処理はもう無理だよね。

オイラなら、まずプロファイラをかける。遅い処理を抜き出して最適化する。DB なら大抵インデックスの張り忘れだね。あとはアホみたいな大きな文字列を作ってる場合なんかもあるかな。いずれにせよ、プロファイラかければ、ほぼ見つかる。

その上で、早い処理が SQL でしかできない場合はもちろんありうるから、SQL をきっちり知ってる必要はあるけどね。でも、そんなことはめったに無い。

で、表題の「演習問題」みたいなやつだけど、オイラの場合なら多分問題を分割するだろうな。(実はあんまちゃんと読んでないんだけどさ。つーか銭勘定のシステムはやったことないし、興味もないんだよね。。。)

ベンチャー社長で技術者で: 上流の技術者はSQLを高いレベルで習得すべき

繰り返します。演習問題ぐらいできなければ、上流の技術者として本来の仕事はできてないです。

って書いておきながら、自分で間違ってるんだぜ。この SQL は複雑すぎる。

もし、「そうじゃない。そんなこと無い」と言い切れるなら、カーニハンの下記の言葉を胸に刻んでおいたほうが良いと思う。

名言 - Kawamura's Wiki!

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are?by definition?not smart enough to debug it. -- Brian Kernighan

そもそもデバッグは、プログラミングに比べ二倍難しい。それゆえ、自分の知恵を振り絞って書いたコードのデバッグをするほどには、あなたの賢さは本質的に十分ではないのだ。 -- ブライアン・W・カーニハン

もし、他のテーブルを参照する必要が出た場合、新しい SQL をどうやってデバッグするのだろうか?それとも、まだまだ自分の本気の 50% 以下しか出していないのだろうか?あるいは「得意先グループ毎に集計」みたいな要件が出たら、もう一個こんな感じの SQL を書くの?

簡単に書けるものは出来る限り簡単に書いて(それは多分 SQL を使わない方法になる)、コードを綺麗に保った上で遅い処理をチューニングするほうが良いと思うけどね。違うのかなぁ。

See also:
勉強にはよいけど、実戦では使ってほしくない事例 - masayangの日記(ピスト通勤他

でも、自分の所のプロジェクトではSQL文でぐだぐだ書くのは禁止している。

  • ロジックがコード本体とSQLとに分散し、追いにくい。
  • 複雑なSQL文はテーブル構造の変更に弱い。
  • 読みやすいコードは実現可能だが、読みやすいSQLは実現不可能なことが多い。SQL文の意味を説明する資料が別途必要。仕様変更の際の手間が増える。