ORMって本当に便利か？

1 ：10/10/05 〜 最終レス ：11/11/28

とかくSQL原理主義者から
・ORMはSQLがかけない雑魚のためのもの
・こんなのに学習コストをかけるのは時間の無駄。そんな暇があったらSQL勉強しろ
・簡単なことを無駄に複雑にしてるだけ。ORM使うと逆に生産性が落ちる
と叩かれがちなORM。みんな本当に便利に使ってる？

2 ：

　　　　　　　　　　　　　　　　　　　　　　　　 2010年10月5日
　　　　　　　　　　　皆様へのお願い
　 このスレッドは高次機能障害をもたらす
病理の臨床実験のために立てたものです。
　 被験者と研究員のやり取りに使うため、
書き込み等は自重されるようお願いいたします。
もし、書き込み等をすることで不愉快な思いをされましても、
当研究所は責を負いかねます。
　　　　　　　　　　　　　　　　　　　　　 (社)京都微生物研究所

3 ：

web板でおk

4 ：

ORMライブラリも色々あるだろ
どのライブラリのことを考えているかによって話しが変わってくる
phpなんかはORMを名乗っているツールはあってもpythonやrubyの
ORMライブラリと比較すると、くずしかないし

5 ：

>>1
ORMはマジで糞だよな。
生産性悪いはパフォーマンス悪いはでアプリを使う側にとっては
大迷惑

6 ：

パフォーマンスが悪いって意見には同意しかねるな。面倒なのはN+1問題と再帰SQLくらいだろ。
ORMの欠陥は2度目のSQL学習をさせるのに等しいくらい導入に時間が掛かることか。

7 ：

このスレッドは天才pンジー「アイちゃん」が
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

8 ：

このスレッドは天才pンジー「アイちゃん」が
言語訓練のために立てたものでした。
アイと研究員とのやり取りに利用するスレッドでしたが、
未知の感染症によりアイちゃんは死んでしまいました。
関係者以外の方もどうぞご自由にお書き込みください。
　　　　　　　　　　　　　　　　　　京都大学霊長類研究所
【生物】京都大学霊長類研究所のニホンザル大量死、さらに増加--未知の感染症か
http://gimpo.2ch.net/test/read.cgi/scienceplus/1278655366/

9 ：

ORMとか使うと１０年後保守するとき大変だ。

10 ：

どう考えても必須
逆にどうやったら使わずにまともな開発ができるのか知りたい

11 ：

SQLそのまま書くよ。

12 ：

そんなことは分かってるが、取得したレコードセットからオブジェクトへ値を
コピーするようなコードをわざわざ書いているのか、それともレコードセットを
そのまま使うようなやり方をしているのか、いずれにしても今どきありえない。
SQLも主キー検索みたいな単純で定型的なものまで人が書く必要はないはず。
あぁ、もちろん使い捨ての小さなツールとかなら話は別だけど。

13 ：

でもORM使うならそれに合わせたテーブル設計じゃないとね。

14 ：

プロジェクト的にツール使って自動で吐き出すってアプローチが有効か否かって話があって、
有効の場合でも、フリーで出回ってるものを使うか、システムに特化したものを用意するかって所じゃないのん。

15 ：

ORMの学習面の問題にぶち当たるたびにiBatis最強説が起きる。
実際に最強なんだろう。

16 ：

>>4
それは言えてる。
ORMはSQL直接書くより遅くて低機能なわけだけど、PHPの場合、それ以前の問題がある。
PHPに、PerlのDBIx::ClassだとかRubyのActiveRecordみたいな高性能なORMがあればORM使おうかとも思うが、現状ろくなのがない。

17 ：

>>16
Doctrine とかじゃダメなん？
自分にはあってなかったんで結局自作したけど

18 ：

ORM使うぐらいなら、RDBMS使うの止めて、NoSQLにしたほうがいい。

19 ：

それはない。トランザクションがちゃんとしてないデータベースはデータベースじゃない

20 ：

それは勝手な定義。

21 ：

PythonのSQLAlchemyとかはデータベースの行とクラスのインスタンスが
1対1に対応しているけど、PHPだと、データベースのテーブルを扱うクラス
があるだけで、ORMって感じがしないよね

22 ：

>>18
ORMはNoSQLを実現するための一つのソリューションなんだが

23 ：

ソリューションｗ

24 ：

LINQは？

25 ：

"ORM が危険なアンチパターンだっていうのはどれだけ言っても言い過ぎることはない"
http://tech.a-listers.jp/2011/06/16/orm_is_an_antipattern/
・ORMはSQLベースのモデルよりも最初のうちはシンプルで理解しやすく、手早く書く事ができる。
・効率はどんなプロジェクトでも最初の頃は十分。
・不幸にもそれらのアドバンテージはプロジェクトが大きく複雑になると消失し、
　抽象化は破綻し、開発者はSQLを使わなければならなくなる。
・ORMの抽象化はほぼ100％のプロジェクトで破綻する。
・オブジェクトはリレーショナルなクエリの結果を表現するのには不適切。
・不適切にクエリをオブジェクトにマッピングすることによって、ORMを廃止しない限り
　簡単には修正できない非効率性がアプリケーションのあちこちにばらまかれる
・オブジェクト指向設計はリレーショナルなデータを効率的に表現できない。
　これはORMが解決できないオブジェクト指向デザインの根本的な制限だ。

26 ：

データが元々オブジェクトならば、NoSQLにオブジェクトを記録する方がリレーショナルデータベースよりも早い。

27 ：

このスレッドは天才pンジー「アイちゃん」が
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

28 ：

"ORM が危険なアンチパターンとか言っているやつが馬鹿だと思う1つの理由。
この馬鹿は、全部ORMでやろうとする。

29 ：

ORMがSQLよりつかえる場面ってそもそもあるの？

30 ：

SQLをオブジェクト（変数）に
代入する場面ですべて使える。

31 ：

EntityFrameworkのトランザクション周りの気持ち悪さだけ改善してくれたら最強だと思う

32 ：

>>25
ITドカタの現場だと、正規化は悪で、横長のでっかいテーブルを作るのが正義じゃん。
なにも考えずにテーブルと一対一に対応したオブジェクトを作っていっちょあがりって感じで、
シンプルに解決されてるんじゃないかな。

33 ：

横長テーブル、というか「DBサーバのCPUにはなるべく物を考えさせない」って一派があって実はあれはアレであり。
DB鯖のCPU負荷分散はAP鯖のそれに比べて色々面倒だから。

34 ：

最近流行のKVSとは相性が良いんかね

35 ：

>>32
×ITドカタの現場だと、
○お前の会社の現場だと、

36 ：

列志向だとそうなるよね

37 ：

コボラーが現役バリバリのところは横長多いんじゃね

38 ：

これ ； デリミタっていうんだけどさ、これをつけなきゃエラーになるような
そんな言語使ってる奴ってどうみてもゴミだと思うんだけど
もしかして「；」これ打ち忘れてコンパイルエラー出すのが楽しいの？
そうか、二度と話かけんなよ
ゴミグラマは社会底辺

39 ：

誰か天使◆uZeeeに話しかけてやれよ。

40 ：

利休には切腹を申し付ける

41 ：

２０１１年、Ruby,Perl,PHP,Pythonって並べたときにさ
ここで、Ruby以外を選ぶ奴ってマジでなんなんだろうな
今日は不燃物か

42 ：

天使ちゃんマジ天使

43 ：11/11/28

EntityFramework便利だよね