Java⇔RDBのMapping-Frameworkを語るｽﾚ Vol.5

Java⇔RDBのMapping-F ..

126:デフォルトの名無しさん
08/12/07 22:59:25
1人で開発する場合から妥当

127:デフォルトの名無しさん
08/12/08 03:12:38
>>123
スキーマ動的に増える設計のシステム保守してるよ。
案外冗談でもないんだな。これが。

128:デフォルトの名無しさん
08/12/08 03:31:14
むしろひとりだとORMつかってうまーの規模だな。

129:デフォルトの名無しさん
08/12/08 09:43:37
プロジェクトで ORM 導入を考えるときは、
便利だけど使いこなすのが難しいので、メンバーに使いこなせるかどうか
とか考えなければいけないけど、ひとりだと自分の好きなツールを使えるからいいね。

130:デフォルトの名無しさん
08/12/08 19:23:51
メンバーのスキルは期待できない。
SQLなら多少書ける。

っというのであれば、DBUtilsやiBatisあたりを使ってりゃいいんじゃね。

131:デフォルトの名無しさん
08/12/08 21:26:41
スキルが期待できない開発者はSQLもとんでもないのを書くことが多いｗ

132:デフォルトの名無しさん
08/12/08 21:28:09
ぶっちゃけオブジェクト指向よりSQLの方が簡単なので
ORMの説明してもSQLじゃないと出来ないとか言われるのが落ち

133:デフォルトの名無しさん
08/12/08 21:57:54
オブジェクト指向よりSQLのほうが簡単？マジ？
使う側の話だよね？
SQLとの比較ってことは、クラス設計ではなくて、誰かが作ったクラス使う場合だよね。

134:デフォルトの名無しさん
08/12/09 01:52:58
age

135:デフォルトの名無しさん
08/12/09 02:02:31
Entityクラスくらい誰でも作れるだろ

136:デフォルトの名無しさん
08/12/10 23:57:32
禁書って２クールだったのか

137:デフォルトの名無しさん
08/12/11 01:01:18
オレもDBからデータ引っ張るときはSQLで考える方が楽だと思う。
WHEREにORとかBETWEENとか必要で、
GROUP BYでMAXとらなきゃいけないケースが多いからかもしれないけど、
これをORMで、ってなったらゴメンナサイだわ。

138:デフォルトの名無しさん
08/12/11 21:53:12
group byって標準APIであるJPAにもあった気がするけど

139:デフォルトの名無しさん
08/12/11 22:04:15
GROUP BYでMAXはORMでも簡単じゃないか？
テーブル結合とかがかなり面倒って感じかな

140:デフォルトの名無しさん
08/12/11 22:08:42
ORMの場合最初に設計時に関連かいてるからね
FKつけないとかいうトンデモな場所だと使いにくい

141:デフォルトの名無しさん
08/12/12 07:59:47
逆にORM意識して規約に従ったDB設計やっていたら
結合がアホのように簡単になる
スキーマをいじれるときはORMで
いじれないときはSQL重視でやるのがいいと思う