ORMって本当に便利か？

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

　　　　　　　　　　　　　　　　　　　　　　　　 2010年10月5日
　　　　　　　　　　　皆様へのお願い

　 このスレッドは高次機能障害をもたらす
病理の臨床実験のために立てたものです。

　 被験者と研究員のやり取りに使うため、
書き込み等は自重されるようお願いいたします。
もし、書き込み等をすることで不愉快な思いをされましても、
当研究所は責を負いかねます。



　　　　　　　　　　　　　　　　　　　　　 (社)京都微生物研究所

web板でおk

ORMライブラリも色々あるだろ
どのライブラリのことを考えているかによって話しが変わってくる

phpなんかはORMを名乗っているツールはあってもpythonやrubyの
ORMライブラリと比較すると、くずしかないし

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

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

このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものでした。

アイと研究員とのやり取りに利用するスレッドでしたが、
未知の感染症によりアイちゃんは死んでしまいました。
関係者以外の方もどうぞご自由にお書き込みください。

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所


【生物】京都大学霊長類研究所のニホンザル大量死、さらに増加--未知の感染症か
http://gimpo.2ch.net/test/read.cgi/scienceplus/1278655366/

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

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

SQLそのまま書くよ。

そんなことは分かってるが、取得したレコードセットからオブジェクトへ値を
コピーするようなコードをわざわざ書いているのか、それともレコードセットを
そのまま使うようなやり方をしているのか、いずれにしても今どきありえない。

SQLも主キー検索みたいな単純で定型的なものまで人が書く必要はないはず。

あぁ、もちろん使い捨ての小さなツールとかなら話は別だけど。

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

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

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

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

>>16
Doctrine とかじゃダメなん？

自分にはあってなかったんで結局自作したけど

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

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

それは勝手な定義。

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

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

ソリューションｗ

LINQは？

"ORM が危険なアンチパターンだっていうのはどれだけ言っても言い過ぎることはない"
http://tech.a-listers.jp/2011/06/16/orm_is_an_antipattern/

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

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

このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

"ORM が危険なアンチパターンとか言っているやつが馬鹿だと思う1つの理由。

この馬鹿は、全部ORMでやろうとする。

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

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

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

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

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

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

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

列志向だとそうなるよね

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

これ ； デリミタっていうんだけどさ、これをつけなきゃエラーになるような
そんな言語使ってる奴ってどうみてもゴミだと思うんだけど

もしかして「；」これ打ち忘れてコンパイルエラー出すのが楽しいの？
そうか、二度と話かけんなよ

ゴミグラマは社会底辺

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

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

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

今日は不燃物か

天使ちゃんマジ天使

EntityFramework便利だよね

運用始まってから、複数箇所から更新されるテーブルのフラグ項目が間違った値になっているデータを発見した時、バグの原因箇所を特定するのにメチャクチャ苦戦する。

更新用のSQL文字列を必要十分な項目のみで書いていれば、GREPで簡単に特定できるのに、ORMで共通化されているから、特定がやたら困難になることが多い。

結局、プログラマは楽になるが、引き渡されたSEが泣きを見るだけの仕組みだよね。

あ、やっぱり楽になるんだｗ

>>45
本稼動後に発覚するバグや、性能問題から逃げ切れる立場ならw

>>46
お前の会社は、こういう場合プログラマが逃げられるんですね？

お前の会社の、やり方が間違ってると
まだ気づいていないのですか？

SQL排除系のORMは、結合が絡んでくると途端に保守性、生産性が下がる
そしてRDB使ってて結合が出てこないことなんてまずない

view作れば医院で内科医

実はもうORMどころかSQLまで不要になってるけどな

KVSとかのこといってるなら、あんなもんはまだおもちゃ

nosql

やっぱり、ORMって、よく言われるようにベトナム戦争に深入りするようなもんなん？

うん？

Play framework 2に採用されたEbeanってどう思う？

３年後に生き残っていたら評価するよ。

46の書き込みみると、ベトナム戦争そのままの展開でワロタ。

ORMがアンチパターンである11の理由
http://tech.a-listers.jp/2011/06/16/orm_is_an_antipattern/

ORM押すヤツってデータを集合として考えられないCOBOL脳だよな。

kvs 最強ですねわかります

ORM真理教

SQLとDBMSでできることは極力そっちでやって手続き言語からはdbapiそのまま使った方が
明らかにマシンに対する負荷もプログラマに対する負荷も低いわ
ライブラリに習熟して変換先のSQLも考慮しなきゃいけないとかアホすぎる

まったくもってその通り

ストアドはどうかと思う

単一テーブルへの読み込みと登録、更新、削除ならORM使って楽する。それ以外はSQL書く。そうすれば学習コスト皆無じゃない？

単一テーブルへの読み書きなんてほとんどなくね？
マスタメンテくらい？

ORMに自動型変換以外に必要な機能があるとは思わないんだけど、
普通は明示的に型のマッピングを書かせるよね。そんなORMに何の利点があるのか教えてほしい。
RailsのActiveRecord以外で自動型変換があるORMって見たことない。

あと、暗黙的遅延ロードはバグを隠蔽するからいらない。

単一テーブルに閉じた、単純な用途だと準備が面倒で別に楽にならず
複雑なクエリはXMLなりコード中にライブラリ固有のマッピング定義書きまくるより、SQL叩いたほうが早い

ただ、前者はRailsのActiveRevordが、後者はmyBatisがそこそこうまく解決できてると思う

これどうやって書くんだ? -> ライブラリについて調べる -> やっぱ対応してねえじゃねえか!
のループもうやだ
DBMSの抽象化とかされても乗り換えることなんてねえよ

ORMとか常に全件舐めてもまったく速度的に問題なくなってからやれよ
って話

単一テーブルへの読みは正規化きっちりしてるとたしかに、Join必須になりあんまないかもだけど…。
書き込みとか削除は大いに役立つと思う。はいばねーとのときは、テーブル定義からエンティティクラスを自動生成してた。
たしかにその手間はあるが、最初の一人が苦労すれば、他の人は大いに楽できると思ってるよ。

糞
便利じゃなくて
便秘

便利だけど完全なマッピングはできない。
ORMではなくORCぐらいが良かった。

ORC = Object Relation Converter