「DBわかりますか」と問われて「SQLはわかる」と言う人はそれなりに多い。
DBをアーキテクチャ面から理解することをしていない人が多いのでは、
直接触る領域以外はブラックボックスのまま放置している人が多いのでは、
というつぶやき。
その思いを強くしたたのが以下の事例。
Java屋さんを筆頭に、
「DBそんなに強くないけどプログラム強い人」「自称オブジェクト指向な人」が
データベースアクセスまわりの設計実装やると、「すごいもの」が出てくる。
自分はどちらかというと「プログラムよりDBの人」だし、オブジェクト指向そんなに強くないから、
よけいに「うわっ」て思ってしまうのかもしれない。
画面上に、とあるクラス40個分程度のインスタンスに基づく情報を、画面のリフレッシュの都度表示する処理で、
シーケンス追っていったら、40回以上のSELECT文を投げてた。
なぜなら、クラスをインスタンス化する際に、そのクラス自身に実装されていた、
自分自身の情報をDBから取ってくるSQL発行のメソッドが呼ばれていたから。
ワーオ。
確かに、1本1本のSQLは最適化されてる。PKでの絞込みしかしてないし。
これ以上、チューニングの余地がない。
そーじゃない。
最適化されたSQLを40回流すのと、
40レコードを1度で取得できるSQL（もちろんこちらも最適化）を1回投げるのと、
どっちがヨイのか。
ケースにもよるだろうが、たいていの場合、後者の方がパフォーマンスが良いわけだし、
（SQLだけでもParse処理の回数が減るし、SQL以前にDBコネクション周りでも余計に処理が走る）
ココの処理ががパフォーマンスのボトルネックになっている場合、
後者だとDB層でのチューニング（SQLおよびDBサーバーの構成設定）で済むが、
前者の場合、プログラム構造自体を直す（前者から後者に構造を書き直す、など）しなきゃいけないので、
「後からパフォーマンスが問題になった」というケースでの対応が格段にツラい。
DB屋なら、「SQLを40回発行」発想は出てこない。
「SQLは効率よく、少なく」が染み付いているから。
たまに、手段におぼれて100行超えのSQL書いてしまったりする（自分のことだ）けどね。
Java屋さんでは、コレが普通なのだろうか。
身近にあまりちゃんとしたJava屋さんが居ないのでわからん。
この事例だけで、Java屋さんに対する偏見持っちゃいけないよね。
「そんなのオブジェクト指向じゃない」とか、「MVCが・・・」とか反論あるかもしれない。
自分もまだ「わかったつもり」でしかないから、見落としている観点もあるだろう。
ただ、フレームワークとかって、
「準拠してどんなに美しくても、（要求に耐えられないほど）遅いんじゃあねえ」
というのが持論。
こんな考え方の欠点としては、なかなか新しいもの「先行者」にはなれないんだ。
「××って、便利（＝書く人に都合がよい）らしいけど、どうなの？」って思って止まっちゃう。
いけないとは思っているけど、落ち着くまで「ガンバレ人柱」目線で傍観者。
とまあ、いろいろあるけど、まだまだRDBMS抜きにシステムは語れないし、
RDBMSのアーキテクチャをちゃんと理解することは大事だと思う。
SaasだのPaasだのと出てきて、
システムにおけるインフラ・ミドルウェア部分がますます「あちら側」的存在になり、
ブラックボックス化が進んでいく。
ラクにはなっていくのだろうけど、ほんとにブラックボックスでいいのかな。
ラクなのは、「何がどうしてラクになったのか」がわかってないと、いずれドツボにはまる気がする。
