SQLとO/Rマッパーのポエム
http://qiita.com/kantomi/items/f527bc717b10e86335af
に関して、最初にO/Rマッパーを見た時の感想としては、同じ印象をもちました。
O/R マッパはSQL知らなくてもいい説には反対
なので新人研修の際には、ActiveRecordを触らせる前には必ず、素のSQLも手書きで一通り書かせている。phpmyadmin やsequel proを使う場合にも素のSQLを書かざるを得ない。そんなのエンジニアじゃなくて今どきのWebディレクターならやってる。
したがって、ORマッパを使ったところで、二重に勉強しないといけないというのが正解かなと。
わたしが作ってる研修メニューでは、
・素のSQLを一通り覚える
・Railsを通すのではなく、素のRubyにActiveRecordeだけをrequireして、コードの中で接続し、
ActiveRecord::Base.logger = Logger.new(STDOUT)
で、どんなSQLが流れているかを一通り眺めながら、ActiveRecordの各メソッドが発行しているSQLを見せる。
ということをしている。
そこまでして二重に学習しなくてはならないの？って質問には、はいすみません、今どきの子大変ですね。でもソースはちょっとだけ見やすいですね。
逆にSQLをとことん高度にしてアプリまで書いちゃうというアプローチ
実はそういうプロダクトがあった。OracleのSQLはPL/SQLと言って、普通のプログラミングもできる。ストアドプロシジャとか呼んでる奴。プロダクトとしては、KeyWeb Creator という名前だった。しかしながら、そもそもストアドプロシジャの外でPL/SQLをつかう人もいなく、制約も多かったので、陽の目を見ることはなかった。ということで、市場原理の中ではSQLでは最強ではなくなった。
O/Rマッパーをつかうってことは、RDBをNoSQL的に使ってない？
これはYES。複雑なSQL使えないし、基本的な動きは、主キーでダイレクトに取ってくるだけの動きが多い。
心配な点としは、RDBはKVSにくらべて機能が大きいために主キーダイレクトで引っ張ってくるにしても、オーバーヘッドも大きいのではないかという懸念。これはエンジンごとにすごく違う。mysqlはスレッドタイプのコネクションなので、コネクションの接続からしてめちゃくちゃ軽い。
この辺の経験値というのが、業務アプリとユーザーサービスと結構違っている。
業務アプリでは、DBエンジンはOracleでバッチ処理性能が大事
ユーザーサービスは、 DBエンジンはMySQLで、ユーザーレスポンスが大事
ユーザレスポンスを大事にするときって、凝ったSQLを書かないというのが割りと大事。レコードの件数によって、プランが変わるようなのは避けたい。
例えば、画面には数十件しかでないのだから、JOINせずに、主キーダイレクトで20回くらいアクセスが発生しても一向にかまわないのだ。
ここでも、RDBをNoSQLみたいに使ってるという批判はアリそうだけれど、主キーで高速にデータを取ってくるってこと自体は、mysqlに関しては超高速。甘えていい。
NoSQLを使えばいい場面でも、マスタの管理とか、主キーそのものがintで管理されていたりとか、実装レベルで便利だったりする。
