がるの健忘録

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

ORMについて考えてみる

その他技術 DB PHP

ORMで初っぱなボケようとして割とよい感じの「別の意味」が見つからなくてもんどり打ってるおいちゃんでございます*1。
まぁボケっぱなしだと話が続かないので、速やかに本題に。

Object-relational mapping、でございます。O/RMって書かれたりORMって書かれたり。
ここでは面倒なんでORMで。

そのORMですが。
評価については、「まんせー」から「Go to Hell」まで、割と激しい幅がある技術なんじゃないかなぁ？ とか思ったりするんですがいかがでしょうか？
実は、後ほど「ORMに言及する」別のBlogを書こうとしているので、「現時点での」おいちゃんの見解を書いておきたいなぁ、と。

おいちゃんの見解としては
・軽いものはORMで書くけどやっかいなやつはSQLダイレクトに書いたほうが早い事が多いよねぇ
ってのをベースに
・チーム内に「ORMに長けたメンバーがいて厄介な質問でも回答が帰ってくる」んならORM側に寄せますがそうでなければSQL側に寄せます
って感じかなぁ、と。

んで。
おいちゃんが知っている限り。
……いやまぁ「不勉強で触った事もなくてなんとなく新しい技術は毛嫌いしているからORMヤダ」って人がいないわけではないのですが。
どちらかというと「実際に使ってみて(使いこなしたとは言っていない)、一定量のトラブル経験を経て嫌になった」人のほうが、割合的には多いんじゃないかなぁ？ と。

んで。
「一定量のトラブル」については
・そもそもORMという思想では根本的に解決不能な問題(あるのかどうかは知らない：可能性として)
・ORMの実装的に根本的に解決不能な問題(あるのかどうかは知らない：可能性として：これはありそうだなぁ)
・ORMで解決できなくもないが、トリッキーだったり特殊なやり方が必要だったいする(近しいのは見た事があるなぁ)
・ORMで一応解決可能だが、実装が複雑だったり難しかったり知られてなかったり
あたりが割とあるんじゃないかなぁ？ とか思ったりするです。

特に後半2つが割と厄介で。
「チーム内にORMに長けたメンバーがいて厄介な質問でも回答が帰ってくる」んならある程度許容範囲かもしれないのですが、「ORMに長けたメンバーがいなくて、ちょいちょいと調べ物が発生したり、ORM自体のソースコードに潜ったりする必要がある」とかって感じになってくると、途端にストレスの上昇カーブが激しくなってくるかなぁ、と。
さりとて、そのORMに深い思い入れがあるわけでなければ「ものすごいコストをかけてそのORMの微に入り細を穿つところまで習得する必要は、あるの？」とかいう疑問が横切った瞬間に「生SQLでよくね？」的なチョイスに向かう事も、少なくないのではなかろうか、と。

んで。
よくORMの例題に出てくるような「シンプルで単純なSQL」なら、そりゃORMのほうが楽でしょうて。
ただ、そういった「シンプルで単純なSQL」以外が、業務では、出てくる可能性が0ではなくて*2。
その辺を「どうするか？」ってあたりへの回答が
・無理
・トリッキーなやり方で出来る
・出来るけど情報を探すまでが少し厄介
・普通に出来る
ってあたりで色々グラデーションがあるんじゃないかなぁ？ と。

例えばよく言われるあたりが「N+1問題」。
ただまぁ、それ以外にも「なんでこんな変なわかりにくいコードかかないかんねんこれならSQL書いたほうが早いじゃん」的な、etc etc。

その辺を考えると、 https://www.kaitoy.xyz/2015/09/13/orm-is-offensive-anti-pattern/ あたりも、一笑に付す事が、幾分、難しい側面もあるんじゃないかなぁ、とか。

んで。
ちぃと興味深いBlogを見つけたので、少し言及してみたく。
https://qiita.com/niisan-tokyo/items/156eb35c6eeaf07b9b65

1. SQLを書かなくていい！

これが「利点になるかどうか」は、「やりたい事を、SQLとORMのコードで書いて比較」次第なんじゃないかなぁ？ とか思ったり。

そこを前提に。

1.1 SQLという「別言語」を混在させずに済む

それをいうと、PHPを書いててもHTMLだのJavaScriptだのと「完全に無縁」とはなかなかいかないような気もしますし。

あと、個人的な所感ですが、SQLの直書きが許されている場合、似たようなSQLが量産される傾向にあるように思います。

については「環境が悪いだけじゃないかなぁ？」とか思うわけです。
あるいは「ORMになったからといって、似たようなコードが量産されないのか？」という疑問があったり。

1.2 「よい」SQLを作ってくれる

「ナニをもってよいとしているんだろう？」と思ったのですが、

これはSQLインジェクションに対する対処としては定石となる手法ですが、手で書こうとすると割と面倒だったりします。

えぇ………… orz
それは、ないと思うなぁ。

2. ゲッター・セッターの仕組みを利用できる

これは別にORM使わなくても出来る。

3. 所有関係を定義できる

「JOIN使えばいいじゃない」と言うべきなのか「FOREIGN KEY使おうよ」と言うべきなのか。

んで。

1.1 SQLを書かない
中略
SQLをバリバリ書ける人にとっては、SQLが勝手に生成されるORMは自由度がないと思うかもしれません。

まぁ、ここだよねぇ、的な。
んなにバリバリ書けるわけではないのですが、それでも割とちょいちょいと「縛りがきついんじゃ*3」と思う瞬間は、割とちょいちょい。

1.2 JOINを使わないかもしれない

……これは「ない」と信じたいなぁ……知らんが。
ちなもし「JOINを使ってない」場合、

これが絶対に悪いかというと、実はそうとも言い切れません。

と書かれてますが、基本的に「がっつりと悪い」です。

2. 嫌ってる人がいる

「なんで嫌ってるのか？」次第だよねぇ、と。

3. N+1問題

言わずもがな。

と言うわけで。

エンジニアにとって、コード量を少なく可読性をよくできることが、ソフトウェアの品質を上げる有効な手段でありますので、ORMで品質が良くなるのであれば、ガンガン導入していきたいです。

については「品質が良くなるのであれば」使う事に抵抗感はないのですが。
「縛りの結果、変な箇所が生まれる」のであれば、その部分の品質が低下してしまうので、そういった部分にまで「むりくりにORM縛りをする」のは、あんまり好まないかなぁ、と。

んで「むしろ、SQLを書いちゃうと、オブジェクト化ができなかったりします。」でデメリットが出るのであれば、選択肢としてはどちらかというと「んじゃ、ORM使わないほうが効率よくない？」って判断になり得るんじゃないかなぁ？ とか思う訳です。


あと、もう1つ興味深い、こちらはスライドを。
https://www.slideshare.net/kwatch/how-topreventorm-troubles

しかし ORM は、アプリケーション開発者にとっては便利でも

わりとそうでもない(苦笑

ORMによるトラブルは (たいてい) 解決策がある

「たいてい」ってあたりに、色々と味わいを感じてしまいます(苦笑

なんてちょっと軽いところに茶々を入れながら。

背景：ORMによるトラブルが多発
ORMが生成するSQLがクソ いわゆる「ぐるぐる系SQL」
SQLをろくに勉強しないアプリ開発者 そのくせOOPやデザインパターンを得意げに語る ;(
開発効率を上げるためのORMなのに話が違う! ある面では効率が上がっても、別の問題を引き起こしている

この辺、色々と闇の深さを感じます………

DBAがORMを知らなすぎる

この辺は「ど～なんだろうなぁ？」的な。
おいちゃんが「(DBAではなく)プログラマ」だから、「ORMはプログラマが把握してDBAに説明すべきもの」なんじゃないかなぁ？ って思ってしまうので、「DBAがORMを知らないのはヨクナイ！！」とは、あんまり、考えたことがないかも。

んでまぁ……理想が「アプリ開発者がSQLを勉強してくれる」になっているあたり、が、なんとも(苦笑
いや大事だと思うんですよSQL理解するのは。
ただ、この発言の背景にある「アプリ開発者のSQLの不勉強っぷり」に思いを馳せると、色々と、ねぇ………

Prepared Statementではwhere句への追加 などが行えない

については、ここで書いてあるテンプレートやクエリオブジェクトを使う以外にも、割と色々と手段があるので、ぶっちゃけ「困ったことはない」ですねぇ。

ORMでよくあるトラブル

「クエリ発行箇所が特定できない」は、言われてみれば確かに、ですねぇ。
index付け忘れとかは、論外付近の事象ではなかろうか、と。

開発者からのSQLの相談に乗ってあげる

相談に乗って貰えるんなら、是が非でも、是非とも……

心構えその５：金を積む

大爆笑ｗｗｗ
でもまぁ「真理でございます」ｗ

あと。

個人的にお勧めなO/Rマッパーは？ ?

のところで

自作！自作マジお勧め！ 職人が自分の道具作って何が悪い！車輪の再発明なぞ知らんがな！

とかあるのは、心から爆笑するとともに、深くうなずける一文でございます。

ActiveRecord？あれはあんまり…

そなの？
この辺はよくしらない。

あと、地味に「PHPでお勧めのORMが出てない」のが、なんとも………。


とまぁ、ざっくりまとめると。
おいちゃんの見解としては
・軽いものはORMで書くけどやっかいなやつはSQLダイレクトに書いたほうが早い事が多いよねぇ
ってのをベースに
・チーム内に「ORMに長けたメンバーがいて厄介な質問でも回答が帰ってくる」んならORM側に寄せますがそうでなければSQL側に寄せます
って感じかなぁ、と。

もうちょっと、ORMの裏側の仕組み＆コードの書き方がこなれてきたら、もうちょっと印象が変わるような気がするんですけどねぇ。
現状だと「全部ORMのみで、SQLは一切書かない」は、案件にもよるんだけど、ちょっと選択肢としては「難しい事が多い」かなぁ、と。

ただまぁ、つまり「生SQLも比較的容易に飲み込める」タイプのORMであれば、「シンプルなSQLはORMのほうが手っ取り早い」のも事実なので、割と積極的に使いたいところではあるんですよねぇ。
なので、別に「ORM死すべし」とは思ってないあたりが、とてもどっちつかずだなぁ、と(笑

*1:マテ

*2:つまり「一定量存在する」

*3: (C)千鳥 ノブ