5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

ORMって本当に便利か?

1 :デフォルトの名無しさん:2010/10/05(火) 19:26:07
とかくSQL原理主義者から
・ORMはSQLがかけない雑魚のためのもの
・こんなのに学習コストをかけるのは時間の無駄。そんな暇があったらSQL勉強しろ
・簡単なことを無駄に複雑にしてるだけ。ORM使うと逆に生産性が落ちる
と叩かれがちなORM。みんな本当に便利に使ってる?

2 :デフォルトの名無しさん:2010/10/05(火) 20:42:08
                         2010年10月5日
           皆様へのお願い

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

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



                      (社)京都微生物研究所

3 :デフォルトの名無しさん:2010/10/05(火) 22:06:28
web板でおk

4 :デフォルトの名無しさん:2010/10/06(水) 10:14:57
ORMライブラリも色々あるだろ
どのライブラリのことを考えているかによって話しが変わってくる

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

5 :デフォルトの名無しさん:2010/10/06(水) 11:51:10
>>1
ORMはマジで糞だよな。
生産性悪いはパフォーマンス悪いはでアプリを使う側にとっては
大迷惑

6 :デフォルトの名無しさん:2010/10/06(水) 11:57:04
パフォーマンスが悪いって意見には同意しかねるな。面倒なのはN+1問題と再帰SQLくらいだろ。
ORMの欠陥は2度目のSQL学習をさせるのに等しいくらい導入に時間が掛かることか。

7 :デフォルトの名無しさん:2010/10/06(水) 15:46:13
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

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

                  京都大学霊長類研究所

8 :デフォルトの名無しさん:2010/10/06(水) 15:48:54
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものでした。

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

                  京都大学霊長類研究所


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

9 :デフォルトの名無しさん:2010/10/06(水) 20:12:39
ORMとか使うと10年後保守するとき大変だ。

10 :デフォルトの名無しさん:2010/10/06(水) 22:53:05
どう考えても必須
逆にどうやったら使わずにまともな開発ができるのか知りたい

11 :デフォルトの名無しさん:2010/10/06(水) 23:11:38
SQLそのまま書くよ。

12 :デフォルトの名無しさん:2010/10/06(水) 23:58:56
そんなことは分かってるが、取得したレコードセットからオブジェクトへ値を
コピーするようなコードをわざわざ書いているのか、それともレコードセットを
そのまま使うようなやり方をしているのか、いずれにしても今どきありえない。

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

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

13 :デフォルトの名無しさん:2010/10/07(木) 00:13:43
でもORM使うならそれに合わせたテーブル設計じゃないとね。


14 :デフォルトの名無しさん:2010/10/07(木) 10:02:08
プロジェクト的にツール使って自動で吐き出すってアプローチが有効か否かって話があって、
有効の場合でも、フリーで出回ってるものを使うか、システムに特化したものを用意するかって所じゃないのん。

15 :デフォルトの名無しさん:2010/10/07(木) 11:40:15
ORMの学習面の問題にぶち当たるたびにiBatis最強説が起きる。
実際に最強なんだろう。

16 :デフォルトの名無しさん:2010/10/07(木) 12:35:05
>>4
それは言えてる。
ORMはSQL直接書くより遅くて低機能なわけだけど、PHPの場合、それ以前の問題がある。
PHPに、PerlのDBIx::ClassだとかRubyのActiveRecordみたいな高性能なORMがあればORM使おうかとも思うが、現状ろくなのがない。

17 :デフォルトの名無しさん:2010/10/07(木) 21:49:32
>>16
Doctrine とかじゃダメなん?

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

18 :デフォルトの名無しさん:2010/10/09(土) 16:25:29
ORM使うぐらいなら、RDBMS使うの止めて、NoSQLにしたほうがいい。

19 :デフォルトの名無しさん:2010/10/09(土) 22:29:31
それはない。トランザクションがちゃんとしてないデータベースはデータベースじゃない

20 :デフォルトの名無しさん:2010/10/10(日) 05:34:42
それは勝手な定義。

21 :デフォルトの名無しさん:2010/12/12(日) 19:27:08
PythonのSQLAlchemyとかはデータベースの行とクラスのインスタンスが
1対1に対応しているけど、PHPだと、データベースのテーブルを扱うクラス
があるだけで、ORMって感じがしないよね

22 :デフォルトの名無しさん:2011/01/13(木) 23:29:05
>>18
ORMはNoSQLを実現するための一つのソリューションなんだが

23 :デフォルトの名無しさん:2011/03/10(木) 00:17:32.28
ソリューションw

24 :デフォルトの名無しさん:2011/04/30(土) 12:58:36.03
LINQは?

25 :デフォルトの名無しさん:2011/06/19(日) 22:02:51.18
"ORM が危険なアンチパターンだっていうのはどれだけ言っても言い過ぎることはない"
http://tech.a-listers.jp/2011/06/16/orm_is_an_antipattern/

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

26 :デフォルトの名無しさん:2011/06/19(日) 22:44:26.14
データが元々オブジェクトならば、NoSQLにオブジェクトを記録する方がリレーショナルデータベースよりも早い。

27 :デフォルトの名無しさん:2011/06/19(日) 23:51:11.53
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

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

                  京都大学霊長類研究所

28 :デフォルトの名無しさん:2011/06/20(月) 00:25:11.05
"ORM が危険なアンチパターンとか言っているやつが馬鹿だと思う1つの理由。

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


29 :デフォルトの名無しさん:2011/06/20(月) 20:04:45.29
ORMがSQLよりつかえる場面ってそもそもあるの?

30 :デフォルトの名無しさん:2011/06/21(火) 23:19:01.82
SQLをオブジェクト(変数)に
代入する場面ですべて使える。

31 :デフォルトの名無しさん:2011/06/22(水) 20:42:40.91
EntityFrameworkのトランザクション周りの気持ち悪さだけ改善してくれたら最強だと思う

32 :デフォルトの名無しさん:2011/06/22(水) 23:28:16.09
>>25
ITドカタの現場だと、正規化は悪で、横長のでっかいテーブルを作るのが正義じゃん。
なにも考えずにテーブルと一対一に対応したオブジェクトを作っていっちょあがりって感じで、
シンプルに解決されてるんじゃないかな。

33 :デフォルトの名無しさん:2011/06/23(木) 01:41:25.25
横長テーブル、というか「DBサーバのCPUにはなるべく物を考えさせない」って一派があって実はあれはアレであり。
DB鯖のCPU負荷分散はAP鯖のそれに比べて色々面倒だから。

34 :デフォルトの名無しさん:2011/06/23(木) 01:46:40.56
最近流行のKVSとは相性が良いんかね

35 :デフォルトの名無しさん:2011/06/23(木) 03:36:34.79
>>32
×ITドカタの現場だと、
○お前の会社の現場だと、

36 :デフォルトの名無しさん:2011/06/23(木) 05:15:00.44
列志向だとそうなるよね

37 :デフォルトの名無しさん:2011/06/23(木) 07:54:21.89
コボラーが現役バリバリのところは横長多いんじゃね

38 :天使 ◆uL5esZLBSE :2011/07/03(日) 18:25:41.87
これ ; デリミタっていうんだけどさ、これをつけなきゃエラーになるような
そんな言語使ってる奴ってどうみてもゴミだと思うんだけど

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

ゴミグラマは社会底辺

39 :デフォルトの名無しさん:2011/07/03(日) 19:54:49.68
誰か天使◆uZeeeに話しかけてやれよ。

40 :デフォルトの名無しさん:2011/07/03(日) 20:17:32.02
利休には切腹を申し付ける

41 :天使 ◆uL5esZLBSE :2011/07/03(日) 22:22:13.98
2011年、Ruby,Perl,PHP,Pythonって並べたときにさ
ここで、Ruby以外を選ぶ奴ってマジでなんなんだろうな

今日は不燃物か

42 :デフォルトの名無しさん:2011/07/05(火) 20:49:13.05
天使ちゃんマジ天使

43 :デフォルトの名無しさん:2011/11/28(月) 18:32:56.76
EntityFramework便利だよね

10 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)