オブジェクト関係マッピングはアンチパターン ? 40
ストーリー by reo
オワパターンという新語を考えてみた 部門より
オワパターンという新語を考えてみた 部門より
ある Anonymous Coward 曰く、
開発現場にオブジェクト関係マッピング (ORM) が登場してから長い年月が経つが、ORM がアンチパターンだという主張がなされ、一部で話題となっている (Seldo.Com Blog の記事、A-Listers の記事より) 。
発端となったのは「ORM が危険なアンチパターンだっていうのはどれだけ言っても言い過ぎることはない」という Laurie Voss 氏のツィート。これに各方面から返信が寄せられ、それに対して書かれたのが先に挙げた Seldo.com Blog の記事である。
主張の詳細は上述のリンク先を見ていただいた方がよいと思うが、実際 ORM はアンチパターンなのだろうか ? タレコミ者はどちらかというと乱雑に書かれた SQL で苦労してきた経験があるため、ORM はより望ましい手法だと考えていた。/.J 諸氏の見解を伺いたい。
独断と偏見に基づいたORM史観 (スコア:2)
SQLデータベースをまるで単なるデータ置き場のように使うのって、OOP(しか知らない)連中が主に使っていたと思われるMySQLが5.0になるまでストプロはおろかビューすら実装されてない状態だったからじゃないですかね。
本来RDBMSを使う意味っていうのは、SQLを使って「何が欲しいか」だけ指定すれば、データ処理の詳細のロジックを作りこまなくてもオプティマイザがよしなにやってくれるので開発/実行効率がいいというところにあるわけで、オブジェクトをそのまま保存/取出しするなんていうことならそもそもSQLなんていう大オーバーヘッドを持っているRDBMSを使う意味がない。
でもOOPの連中はSQLプログラミングの手段としてのストプロとかビューというものを知らなかったから、その辺がピンと来てなかったんじゃないですかね。だからご苦労様なことにデータ操作のロジックをシコシコOOPで書いていた。というかMySQLにこだわるなら実際そうするしかなかったわけだし。
で、最近はMySQLでもそのあたりのサポートが充実してきたんで、ようやくそのことに気付いた人たちによる揺り戻しが来ていると。
Re:独断と偏見に基づいたORM史観 (スコア:1, 参考になる)
さすがに「ストアド？ビュー？あぁ、忘れてたわ」というレベルの強者はレアかと（笑）
すっげーSQLやらストアドやらを使うと確かに実装速度も動作速度も速いんですけど、
みたいなことが度々あって、面倒くさくなってテスト作成／実行しなくなっちゃうってことありません？
自分はこの流れでDBに複雑な処理を置かなくなりました。
楽したいのは山々なんだけど、
という方針をとっていると、DB内で複雑な処理をやらなくなるのは仕方の無いことなのかなーと思ったり。
Re: (スコア:0)
> みたいなことが度々あって、面倒くさくなってテスト作成／実行しなくなっちゃうってことありません？
> 自分はこの流れでDBに複雑な処理を置かなくなりました。
は？なんでこんなのが"参考になる"なんだよ
DBに処理任せないでも実行速度で困らない程度の実装しかしてないんでしょうか？幸せなんですね。
仕事でプログラム書かれてるなら、なんで商用RDBがあんな複雑な処理ができるのか少しは考えたほうがいいです。
Re:独断と偏見に基づいたORM史観 (スコア:1)
話の流れを考えると「DBに処理を任せないと実行速度で困る」という問題領域を持ち出すのが適切なのか疑問が残ります。
そういうシビアな領域でORMが選択されるとは思えません。このストーリーの対象となる実装は、少なくともORMを適用することができる程度にはリソースに余裕があり、ORMを使わないという選択肢がパフォーマンス以外の理由で検討される場合のことだと思います。
そして、元のコメントは、そういう場合に、ORMを使えるけど使わないという選択をする理由としてそれなりに説得力があると思います。
LIVE-GON(リベゴン)
Re: (スコア:0)
Re: (スコア:0)
なるほど。日本でこの手の議論をしてる人って商用DBか、
OSSでもPostgreSQLを使ってる人が多くて、VIEWくらい常識という印象を受けたので、
議論がかみ合わないわけですね。
煽った言い方をすると、あっちの人たちって低レベルな議論してるんですねと。
Re: (スコア:0)
社内独自実装のORMを使っていますが、大きな処理はストプロで出来るように
ストプロをキックする仕組みは追加で実装されました。
VIEWもロジックをDB側に任せる手段として使いますね。
要は、全部の処理をDBに任せないで
・少量/逐次的なデータ処理→ＤＢ外
・大量のデータ操作→ＤＢ内
と切り分けることが大事だと経験的に感じています。
# BASICからアセンブラをちょこちょこ混ぜながら作る時の感覚ですかね
ハイブリッドできなきゃ (スコア:2, 興味深い)
簡易なSELECT、INSERT、UPDATEはORMで。
それ以外はSQLで書きましょう。
ということのできないORMライブラリや、JOINまでORMで解決しないと
気が済まないリーダーが混乱させているのだと思う。
・DBを隠ぺいしようなんて考えちゃだめ。
・ORMは簡単な処理をいちいちSQLで書かなくて良い、くらいにしとくこと。
・大体、オブジェクトに値を入れるのが面倒で使ってるんだから！
という人は結果セットをオブジェクトに自動で入れる関数でも作ればいい。
・複数テーブルを連結する集計が多かったり画面表示のバリエーションが多いなら、
いっそのことBeanなんてやめちまえ。画面表示でアクセサが必要ならば、汎用BeanのAPIを一度お試しあれ。
・PHPみたいなLLでORMする意味は無い。ハッシュを渡して使える便利SELECT/INSERT/UPDATE関数があればいい。
オブジェクトを直接格納するデータベースを作るよりはましです (スコア:1, 荒らし)
激遅いデータベースを作っていたので、文句を言ったら
MySQL に乗り換えた、という事件がありました。
まだ、これよりは、ましかと。
Re:オブジェクトを直接格納するデータベースを作るよりはましです (スコア:1)
日本語でおk
reininn氏はサイボウズの偉い人か何かで、自社で開発していたオブジェクトデータベースをキャンセルさせてMySQLを採用したって事?
天琉陳(Teruching)
Re: (スコア:0)
これとは別なオブジェクトデータベース？
CyDE (引用者補足：Cyboze Database Engine) はオブジェクトデータモデルを採用している。（ざっくり略）CyDE は、サイボウズ Office のバージョン3 から搭載されており、既に数多くの導入事例と4年の実績がある。 [cybozu.co.jp]
Re: (スコア:0)
こういう記事があったから、CyDE のことでしょうか。
サイボウズ、MySQLを採用 [itmedia.co.jp]
青野氏激白！ サイボウズが [itmedia.co.jp]
Re:オブジェクトを直接格納するデータベースを作るよりはましです (スコア:2)
その記事を読む限り、サイボウズの旧アプリは独自の組み込みDBだったからスケールさせづらかったと言っているだけで、遅かったのと DB が OODBMS なのか RDBMS なのかというのはあまり関係なさそうに読めますね。
組み込みDBは単体サーバで動かすなら軽量でしょうけど、利用者が1000人、1万人と増えてきて、Webサーバを増設したいといった面では不利かな。で、それは RDBMS（SQL Server CE とか）にしたところで多分同じ。
Re: (スコア:0)
key-value storeはどうなんでしょ (スコア:1)
Hibernate = アンチパターン (スコア:0)
どれも使ったことなくて記事での紹介やブログだけの印象ですが、
Hibernate: 最悪。間違いなくアンチパターン。
ActiveRecord: RoRが使える領域に限れば問題ないと思う。
Doctrine: 全く知らない
あとMyBatisとかS2DaoとかSQLを活かすフレームワークはこのパターンに当てはまらないような感じですね。
なので、実質的にはHibernate = アンチパターンだと思います。
Re: (スコア:0)
> どれも使ったことなくて
それがすべてを物語ってるんじゃないの?
使ったとことない = アンチパターン・・・なわけないだろ (スコア:0)
よって、有効なパターンは数あれど、使ったことのあるパターンは数パターンってのはよくある話。
アンチパターンだと判断できるのは、要求とマッチして、使った事がある人だけ。
Re: (スコア:0, 荒らし)
じゃあ使ったこともないのにHibernateをあそこまでdisってる
親コメントはどっちにしても支離滅裂なわけだ
Re: (スコア:0)
Re: (スコア:0)
挙げてるものを使ったことがないだけで、ORM自体使ったことないわけじゃないですよ。
Hibernateはちょっと検索してみれば分かるけど、あまりに酷いというコメントばかりで、
使わなくても想像するだけでこりゃおかしいなと分かります。
Re:Hibernate = アンチパターン (スコア:4, すばらしい洞察)
「おかしい」とか抽象的な事書くからおかしなコメントがでてくるわけで。
自分がHibernateちょっと使って思ったのが、使い方覚えるのに時間がかかりそうということです。
SQL書けない人でも使えるか又は、SQL直接書くより楽じゃなければORマッピングツール使う意味なんて無いわけだけど、Hibernateにはどちらも当てはまらないと思いました。(Hibernateバリバリ使いこなせるようになれば違うんだろうけど)
コメントが沢山あるのは、ORマッピングツールとして世に出てきたのが最初の頃だったからかと思います。
その点、S2Daoは現実的に使えると感じます。
親コメのアンチパターンかどうかは自分にはわかりませんが、もっと良いパターンあるのでしょうか？（今より工数かからず安全に作れるパターン）
Re:Hibernate = アンチパターン (スコア:2)
Re: (スコア:0)
マッピングツールという名前がそもそも詐欺的。結局SQLを発行している以上SQLのパフォーマンスを超えられるはずがないわけで、ラッピングツールとでも言うべき。
NoSQLみたいなDBMSを直接操作できるようなツールなら話は別だろうけどもはや関係データベースにマッピングしてないし。
Re: (スコア:0)
一応こちらにもコメント。
> SQL書けない人でも使えるか
これが破綻してると思います。
まず、ORMの一番の問題はパフォーマンスが出ないことで、
SQLを使うように変えたら何倍～何十倍も速くなることはざら。SQLが不要ということはないです。
本当に最小限のプロジェクトなら問題ないとしても、
そのためにJava + Hibernateというのが重すぎます。(なのでRoRは否定してない)
次に、中でどんなSQLを発行してるのか分かりにくいことです。
無駄なSQLを発行してパフォーマンスが落ちたり、Lazy/Eagerローディングの問題があったり。
一方、生のSQLは単独で実行できるので、デバッグもしやすく、パ
Re: (スコア:0)
> 次に、中でどんなSQLを発行してるのか分かりにくいことです。
C/C++/アセンブラ使いが他の高級言語に対して抱く感想そっくりなのが面白い。
でも「DBMSのオプティマイザがどんな機械語コードに展開するかわかったもんじゃないからSQLなんか信用できん」と言ってるC/C++使いは見たことないなあ。不思議だ
Re: (スコア:0)
・遅くなる問題の質が違う。例えばJavaだとせいぜい無駄なコードが入るくらいだけど(ただしGC問題除く)、
Lazy/Eagerの「N+1検索問題」は本質的に別のロジックが動く。
http://s2container.seasar.org/2.4/ja/s2jdbc_abstract.html# [seasar.org]トラブリにくい
・元コメに書いてあるけど、抽象化でむしろ開発効率が落ちるという大きな問題がある。
似てるようで全然違いますね。
Re: (スコア:0)
Re: (スコア:0)
＞あまりに酷いというコメントばかり
なんでそれだけコメントがいっぱいあるのか。
ってところが鍵かも。
あとどこがひどいのか理解せずにヒドイっていうのもヒドイかと。
# javaはポインタが無いからヒドイ。ってよく言われてたな・・・
Re: (スコア:0)
Eclipseのpluginを使った開発環境込で考えれば、
アドホックな開発用途で使う分には、十分アリだと思うけど？
Re: (スコア:0)
元記事では、
> 当初は有益だが、長期的にみると良い結果以上の悪い結果を招く。
なので、アドホックには使えるというよりは、アドホックにしか使えないということ。
Re: (スコア:0)
古いですけどこんなのとか。
http://www.tsuyukimakoto.com/blog/2005/09/23/145/ [tsuyukimakoto.com]
今この問題解決してるなら教えてくださいｗ
Re: (スコア:0)
シチュエーション１、２、４は解決済みですよね。
３、５はHibernateでなくてもORマッパを使っている限り同じ問題が発生するのでは？
どちらにしろ、使い方を間違っている可能性が大きいと思います。
別にHibernateを擁護する気はないですが、
批判だけして代替案を提示しない姿勢には賛成できませんね。
Re: (スコア:0)
> どちらにしろ、使い方を間違っている可能性が大きいと思います。
これは「バッドノウハウ」ですね。
普通に使ってて使い方を間違っていると言われるのは設計が間違っているパターンがほとんどですよ。
> 別にHibernateを擁護する気はないですが、
> 批判だけして代替案を提示しない姿勢には賛成できませんね。
他の書き込みでいくらでも代替案は書いてますよ。
例えばJavaならもっと薄いSQLを生かしたフレームワークを使えばいいだけ。
Re: (スコア:0)
http://d.hatena.ne.jp/koichik/touch/20051007/1128711612
使いよう次第 (スコア:0)
とはいえ、ORM を使った場合、オブジェクト指向らしいデータ構造の設計と、RDBMS らしいデータ構造の設計を両立させることができずにいるため、常に気持ち悪さを抱えながら設計していることも事実です。私が感じる気持ち悪さは、たぶん下記のような理由から来ているように思います。
RDBMSではデータを正規化によって細分化していき、別々のテーブルに分けて格納するようにします。これに対し、オブジェクト指向では、関連するデータを一箇所にまとめてカプセル化し、インタフェースを決めて細部を外部から隠蔽していこうとします。
まとめようとする考え方と、分けようとする考え方のはざまで実際のデータ構造を決めることになるから、どちらか一方から見たら中途半端な考え方になっているのだと思います。みなさんは、オブジェクト指向らしいデータ構造と RDBMS らしいデータ構造の本質的な不一致ってどこだと思います？
Re:使いよう次第 (スコア:2)
ロックしたいデータ単位とか構造とか。
Re: (スコア:0)
結合したレコード構造がオブジェクト指向に一致しないとこかな
Re: (スコア:0)
なるほど、ビューとかストアドプロシージャというものの存在を知らないOOP畑の人間 [srad.jp]の実に見事な実例ですね。
正規化された表というのはOOPに無理やりたとえるとプライベートメンバみたいなものなわけですが。
Re: (スコア:0)