gallu’s blog

エンジニアでゲーマーで講師で占い師なおいちゃんのブログです。

ORMについてのとりあえずの所見

元ネタっていうか刺激元は此方。


[db] 「O/Rマッパーがなぜ悪いか?」がなぜ頭悪いか?
kwatch.houkagoteatime.net/blog/2014/12/27/nabokov7/


些か検証仕切れていない部分はあるんだけど。
現時点において
・本質的な部分
・現在(っつか正確にはちょい前)の実装的な部分
のどちらでも、気になる部分が少なからずあるので、端的に書くとおいちゃんは「好まない」感じ。


・現在(っつか正確にはちょい前)の実装的な部分
が単純なんで先に書いておくと「いらんSQL流しすぎで重すぎで結果DBに負荷かけ過ぎ」なのでお好まん。
ただ、これは「改良されつつある」話も耳にするし、きっと「改良されていくだろう」と思うので、現時点ですでに枝葉末節な気もする。


・本質的な部分
で一個、物凄く大嫌いなのが「ORMを使えばSQLを知らなくてもイイ」って論調でなんて言うか「滅びろ」。
「理解した上で、今この瞬間は一端未考慮のブラックボックスでもイイ」はアリだけど「知らなくてもイイ」とかなんていうか「ディスインテグレート(分解消去)」の禁呪唱えてやるから滅びろ。


で、考察に値するのがそれ以降。
「ある一定のほにゃららを部品化して使い回せる」部分は、時々欲しいなぁと思う瞬間はあるんだけど。
ただ実際問題としては「その辺をメソッド化」して切り出せば割と十分にいけるので「無いと困る! 必須!」ってほど強いモチベには繋がらない。


逆側の否定として「SQLガリガリのチューニング」は、それはそれでお好まないので「SQLならチューニングしまくったものが渡せる! だからORMは駄目!!」ってのは、それはそれでおいちゃんの心をつかまない。
…多分おいちゃんが「Webアプリが多いから」ってのに起因。
業務系だと「ややこいSQLガリゴリっと」ってのに一定の利があると思うし。
一方で、Webアプリにおいてはどちらかというと「シンプルなSQLを高速大量にぶん回す」事のほうが多いし、そっちを「軽快に」動かす方がメリットあると思うので。


また「インピーダンスミスマッチ」の問題も気になるところ。
とりあえず「生SQL書いている時」に、やっぱり「OOPとは違う脳みそ使ってる」なぁ、とは思うので、その辺はあると思う。
それを「どれくらい美味くマッチングさせられるのか」「やっぱり難しいのか」ってのは、まだ考察仕切れていない…けど、やっぱり「ちょっとOOPとは違うよね」って思う瞬間はあるし、それを「じゃぁOOPにすり寄っていただきましょう」って方向の流れは、どちらかというと違和感がある感じかな。
「最終的なデータの塊」自体は、OOP集合論とで(ある程度かもしらんが)マッチさせられると思ってるので(っていうかそこで困ったことは無いので)。
SQLでデータの塊作って
・それをインスタンス(の配列)にして
くらいでいいかなぁ? って思う事が、正直、多い。


そうすると…


「シンプルなSQL」を回すぶんには、どっちも大差なくて、ってことはつまり「ORMなら部品化出来るよ!」言われても、そも、部品化が必要なほどの状況もほぼなくて。
「ややこいSQL」を使う場合、やっぱり「チューニングしたいよねぇ」って話もあって、それは「将来のORMなら」潤沢に出来るかもしれないけど、現状出来ている訳ではなくて、ってことはここについては「ガリッゴリのSQLを生で書ける」ほうが、どちらかというと現実的で。
あとぶっちゃけ「ORMによって色々書き方とかお作法とか違う」ので、覚えるのめんどい。
SQLは良書あるんだけどねぇ。
ORMにそーゆー良書あるのかしらん? あったら読んでみたいんだが。

プログラマのためのSQL 第4版

プログラマのためのSQL 第4版

達人に学ぶ SQL徹底指南書 (CodeZine BOOKS)

達人に学ぶ SQL徹底指南書 (CodeZine BOOKS)


この辺を考えると。
「全てのORMを生まれる前に消し去りたい。すべての宇宙、過去と未来の全てのORMを、この手で」ってほど滅びろ、とは全く思わんのですが。
「現時点のORM」は、覚えるコストとかバックのチューニングとか諸々考えた時に、おいちゃん的には「現時点においてはお好まんなぁ」、って判断にとりあえずなるわけです。


ただ一方で「お好まん状況が一式払拭される未来の可能性」が常に頭によぎるので、定期的に何となく「どうだろう?」って覗いている感じ(笑


というわけで、現状の「覗いている結果」を、備忘録のようにメモり。