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

1 ：デフォルトの名無しさん：03/03/30 22:17

●各種Framework
[Torque]
http://db.apache.org/torque/
http://homepage1.nifty.com/kingyoshi/computer/jakarta/torque.htm

[HYBERNATE]
http://hibernate.bluemars.net/1.html

[CasterJDO]
http://www.castor.org/jdo.html
http://www-6.ibm.com/jp/developerworks/java/021025/j_j-castor.html

[ObJectRelationalBridge (OJB)]
http://www.terra-intl.com/jakarta/ojb/

●コネクション・プーリング
[Jakarta Commons DBCP]
http://jakarta.apache.org/commons/dbcp/
(Jakarta Commons DBCPを使ってみよう。)
http://taka-2.com/jclass/DBCP/
(DBCP利用法 from "『カモン!Commons!』 Jakarta Commonsを使ってスキルアップ" (2002/09))
http://www.mobster.jp/wiki/index.jsp?pid=Commons#i10

2 ：デフォルトの名無しさん：03/03/30 22:18

性能、パフォ、実績、事例など情報を持ち寄りませう

3 ：デフォルトの名無しさん：03/03/30 22:19

Hybernateが結構よさげなんだけど、日本語リソースって見つからない。。。

4 ：デフォルトの名無しさん：03/03/30 22:39

>>1
もうちょい時間おいてから
スレたてたほうがよかったかもしれない
JDOも発表されてまだまだ浸透してない
この辺はまだ過渡期だからな

5 ：デフォルトの名無しさん：03/03/30 22:42

Torqueは、けっこー浸透してきたイメージがあるんだけど、
まだまだなんかな？

6 ：デフォルトの名無しさん：03/03/30 22:49

>>5
トルクはまだいいけど
比べる対象が無いって言うのが現状（っていうか使わないから知らんだけなんだが・・・）
使ってる人がいればいいんだが日本語Docがなさそうなので
俺にも勉強する気ない。
仕事で、いやがおうにも使わないといけない状況にならないと
読む気しないんだな英語は・・・忙しいし

7 ：デフォルトの名無しさん：03/03/30 22:56

とりあえずJDOをどのように解釈して
発表してくるのか
ベンダの動きを見てみないとわからん
まあ、そう遠い日の話じゃないと思うが・・・

まあ、Torqueに限ればロギングが
Loｇ４ｊっていうのがどうも気に食わない

8 ：デフォルトの名無しさん：03/03/30 23:07

仕事でJDKが、1.3と指定されれば、Log4jが現実的か。。。

9 ：デフォルトの名無しさん：03/03/30 23:10

>>7
Log4jで、JDK1.4 LoggingAPIにリダイレクトするアダプタ作ればｴｴﾔﾝ。
大して難しくも無いさ。

10 ：デフォルトの名無しさん：03/03/30 23:13

>>9
うん、がんばってみる

11 ：デフォルトの名無しさん：03/03/30 23:45

アプリ内の各モジュールから、JDBC経由でｺﾞﾘｺﾞﾘSQL投げるのって
ｺｽﾄかかりまくりだよね。最低限ｺﾈｸｼｮﾝﾌﾟｰﾘﾝｸﾞするとしても、
それプラスこういったフレームワーク使うとしたら、現時点では
トータル的にどれがベストチョイスだろう？
フレームワーク内でCPやってくれるやつってあんのかな？

12 ：デフォルトの名無しさん：03/03/30 23:55

>>11
EJBはCPが当たり前でつ。

13 ：12：03/03/30 23:55

つうかJDBC2.0は自動的にCPです。

14 ：デフォルトの名無しさん：03/03/31 23:10

もうSQLは書きたくないでつ

15 ：デフォルトの名無しさん：03/03/31 23:50

EOFﾏﾝｾｰ

16 ：デフォルトの名無しさん：03/03/31 23:58

>>14
EJB 2.0　CMPで、SQL書くのをやめられるよん。

17 ：デフォルトの名無しさん：03/04/01 01:38

ちょうどtorqueを昨日動かして見ました。JavaWorldの記事を読みつつ。
でも、ちょっと情報少ないかな。jakartaのCriteriaHowToとか読んでも
情報不完全で、詳しい使い方が判らない。

今悩んでるのは、複数のテーブルをJoinしてSelectする際に
各テーブルのカラムの値を同時に取ってくる方法ってあるんですかね？

つまり、role_idとrole_nameを持つRoleというテーブルが有り、
permission_idとpermission_nameを持つPermissionというテーブルが有り、
role_idとpermission_idを外部キーとして持つRolePermissionというテーブルが有る時に
関連付けられているrole_nameとpermission_nameを同時に取得したいのですが、どうでしょ？
torqueだと無理なのかな。

18 ：デフォルトの名無しさん：03/04/01 02:44

>>17
勘コード。

Criteria crit = new Criteria();
crit.add(RolePermissionPeer.ROLE_ID,"ROLE");
List t = RolePermissionPeer.doSelect(crit);
RolePermission r = (RolePermission)t.get(0); // 一行Hitを想定ね
String roleName = r.getRole().getRoleName();
String permissionName = r.getPermission().getPermissionName();

・・・雰囲気はこんな感じか。細かいことは覚えてないからよろしく解釈しておくんなまし。
外部キーと一意制約がちゃんとschemaで定義してあれば楽なはず。

ただしこのまんまやると恐ろしくパフォーマンス悪い罠。
CriteriaのLeftとかRightとか言うメソッド（があったはず）を使うといいのかもしれん。(うろ覚えな上未検証)
あと各BasePeerにdoSelectJoinなんたらというprivateで隠されてるメソッドもあったりする。かも。

なんかいろいろ悪い夢を見たきがするなぁ・・・・。

19 ：デフォルトの名無しさん：03/04/01 02:50

EJB2.0の Many to ManyのCMRを利用するとよさそうだけど。
BEAやIBMのEJBサーバが賢いこととを期待して。

20 ：デフォルトの名無しさん：03/04/01 11:14

>>18
レスありがと。
でも、それだとDBへの問い合わせが恐らく3回発生しますよね。
確かにパフォーマンスが悪い。

もうちょっと僕も調べてみます。

21 ：デフォルトの名無しさん：03/04/01 14:17

>>18
>あと各BasePeerにdoSelectJoinなんたらというprivateで隠されてるメソッドもあったりする。

ソース読んで実験もしてみました。該当のメソッドを使用すると
一度のSQL発行だけで複数のテーブルの値を同時に取ってこれました。

ただチュートリアルにも書いてあったとおり、1つのテーブルしかJoinできず
例えばdoSelectJoinAllのようなメソッドは存在しません。
http://www.jajakarta.org/turbine/jp/turbine/torque/tutorial.html

となると、doSelectJoinなんたらのコードを参考にしてユーザが
実装するしかなさげです。

しかしdoSelectJoinなんたらのコードを読むと、
BasePeer.doSelectで取得したListから重複してるOM Classを除去している？
様子なので、JOINするテーブルの数が多いと面倒・・。

SQLの発行回数が気にならなければ、簡単に書けるのですが。

22 ：lilac：03/04/01 14:22

eBrain21.comは、インターネットユーザーがホームページを
掲載するにあたって必要なサーバースペースを有料レンタルしています。
お客様に快適なサーバーを提供するためにさまざまなホームページの目的に応じて、
単なるホームページスペースだけではなく、動画やゲームまたは個人放送はもちろん、
そのツールとしてCGI、PHP、SSI、SQLデータベースなどあらゆるサーバースペースを提供しております。

http://www.ebrain21.com/

[email protected]

23 ：デフォルトの名無しさん：03/04/01 17:22

Java⇔RDBのMappingのFramework俺作ったよ。しかも、中規模のシステムで安定稼働してるよ。
下記以外ならSQLを書く必要はありません。
一般的に使用頻度の少ない演算子や関数を使用するSQL文の場合。
万が一、複雑なSQLが必要な場合オーバーライドで対応する。
Torqueは設定がめんどくさい。あんな設定が必要なら、チームで開発する場合SQLを書いた方がまし。
しかも設定する情報はDatabaseMetaDataクラスで実行時に取得できる。
EJBやるやつバカ。そのうち無くなるよ！！

24 ：デフォルトの名無しさん：03/04/01 17:28

>>23
こうばしいな

25 ：デフォルトの名無しさん：03/04/01 18:28

>>23
ｵｰﾌﾟｿﾝｰﾇで公開しる！
ライセソヌは、ApacheヌタイﾉﾚかBSDライセソヌで。

26 ：デフォルトの名無しさん：03/04/01 23:12

>>23
あんたのそのやり方のほうが時代遅れなワケですが。

誰がそのフレームワークの仕様を管理し、メンテするの？
誰がそのフレームワークの利用方法を教育するの？
そのコストはﾀﾀﾞじゃない。少なくともアンタの人件費分はかかるわけで。

標準仕様なら、多分たくさんのデベロッパがリテラシを各自で抱えることになる
ので、そういうコストが格段に少ないのですよ。こういったことを考えられない、
半可通技術マンセー馬鹿が、よく俺様フレームワークを書いて悦にいってるんで
すよね。あーやだやだ。

27 ：デフォルトの名無しさん：03/04/01 23:16

多くのエンジニアに共通で認識されているということの重要性をわかってないんだね。

28 ：デフォルトの名無しさん：03/04/01 23:42

>>23を弁護するわけじゃあないけど、、、

じゃあ、どのORマッピングツールが標準仕様となって
将来に渡っても安心して利用できるかどうか判断できるのかと問い詰めたい。

ないならないで作るのが正しい技術者の態度だと思うんだが。
そうすれば、少なくとも自分の面倒みているプロジェクトでは安心して利用できるじゃん

一知半解たあ、>>26のことじゃないの？

29 ：26：03/04/01 23:45

>>28
オプソでデファクト候補がいくらでもある分野でそれをやるのは
アホの所為。ないなら作るのは、しかたないと思うけどね。

30 ：デフォルトの名無しさん：03/04/01 23:47

>>28
別に将来の話をしてるんじゃない。
今すでにあるものが使えて、多くの技術者に認識されているものなら、
独自仕様突っ走るよりいいんじゃないの？
ってだけなんだけど・・・・

31 ：26：03/04/01 23:56

ORマッピングについては、EJBの新しい仕様がAPサーバに内蔵させる
という方針で固まっている。(細かい仕様はｼﾊﾞﾗｸ右往左往するかも
しれんけど)
遠い将来にわたって使用できるものなど必要ない。なくなるんだから。

32 ：デフォルトの名無しさん：03/04/02 00:04

というか、26は何が言いたいのかがわからん。

>>29でデファクトスタンダードになる候補があるのに実装するのはアフォと言いつつ
>>31では現状の実装でデファクトになるもんなんざあないとおっしゃる。

あと、ちょっと別の話になるけど、
EJBってEJBコンテナが無いと利用できないんだよ？知ってる？

33 ：デフォルトの名無しさん：03/04/02 00:13

TorqueでテーブルをロックするのってTorqueクラスでgetDBして
取得したDBのlockTableメソッドを呼び出す・・であってます？

でもDBPostgres.javaとかの中身を見るとメソッドの中身が空ですが・・。
それにhttp://db.apache.org/torque/db-adapters.htmlの

Databases that only support table level locking obviously
do not require this method. Databases that support row level
locking must implement this method to avoid synchronization problems.

というのも訳わからんし。なんでテーブルロックをサポートしているDBが
lockTableメソッドを必要としないのかしらん？
もしかして別な方法でロックできたりしますか？

あとFOR UPDATE付きでSELECTしたい場合とかはどうしたらよいのだろ。

34 ：デフォルトの名無しさん：03/04/02 00:22

>>32
EJBコンテナは、今日びオプソ版もベンダ製無料実装もありますし。

35 ：デフォルトの名無しさん：03/04/02 00:43

>>34
うーむ。DBアクセスをSQLレスで手軽かつ柔軟に実現できるフレームワークとして
Torqueに期待したのですが、今の状態ではやっぱり使えないですねぇ。
EJBもEJB-QLの機能は貧弱だし、BMPにすると結局はSQLを記述する事になるしで・・。

36 ：デフォルトの名無しさん：03/04/02 01:11

Jakarta が EJB コンテナのフル実装に行かないのは、やはりそこらの企業と
暗黙の了解があるのだろうか。

37 ：女□：03/04/02 01:18

うーん

SQLに強い奴一人連れてきて
そいつに仕様叩き込んで　必要になりそうなセレクト文は全部viewにさせて
アプリからの呼び出しは　「select * from びゆ where ふがふが」　のみにする　ってのが最強だと思ってたんだけど
最適化されたSQLが残って　メンテするやつも勉強になるし

更新系は業務ベースで更新対象をモデル化して、モデルクラスをポコポコ作って実装してもらう
コネクションの管理（取得と返却とコミとロルバク）はモデル達の基底クラスにやらせる
更新系は長くて複雑なＳＱＬなんて出てこないだろ（甘いか）

38 ：女□：03/04/02 01:21

ＤＢのフレームワークってＳＱＬを手で書かなくていいようにするのが目標なのかね
ＳＱＬは手でモロに書くものだと思ってるから　かなり受け付けない

オラクルしか使ったことないからこんな考えになるんだろうな

39 ：デフォルトの名無しさん：03/04/02 10:03

>>38
EJBの目標は、ストレージの形態に依存しないインターフェイスにすること。
RDBだろうがOODBだろうがebXMLだろうが、未知のより進歩的なストレージだろう
がシームレスに使えることが目標なのよ。

だからEJBは、RDBに対して最適化されたインターフェイスが提供されるわけじ
ゃないのよね。RDBから自由になるって言う発想は、想定外？

40 ：39：03/04/02 10:05

とはいっても、当分現実はRDB相手ｵﾝﾘｰだろうケドネ。

41 ：デフォルトの名無しさん：03/04/02 14:14

TorqueにしろJDOにしろ可読性がもう少しどうにかなると助かるんだが．．．

42 ：デフォルトの名無しさん：03/04/02 15:19

>>39
> RDBだろうがOODBだろうがebXMLだろうが
これって、多次元DBについても言える？
実装はともかく、方針とか、目標とかの話で。

43 ：デフォルトの名無しさん：03/04/02 21:52

Torqueを導入した事例ってあるのですかね？
かなり使えないっぽいんだけど。

44 ：デフォルトの名無しさん：03/04/02 22:23

めんどくさいのはSQL作ること自体より、JDBCプログラミングするとこだと思ってるんですが

45 ：女□：03/04/02 23:13

>>39
>RDBだろうがOODBだろうがebXMLだろうが、未知のより進歩的なストレージだろう
>がシームレスに使えることが目標なのよ。

ＤＢにあんな皮こんな皮かぶせてjavaで使えるようにするより
javaに合わせたデータベース作った方が早いと思うんだけど

なんとかを継承したクラスでstore()メソッド呼んだら
テーブルにデータが保存される（テーブルなかったら勝手に定義される）とか
そういうのはないのかね

46 ：デフォルトの名無しさん：03/04/02 23:54

>>42
DWHとかOLAPとかはOut of 眼中じゃないの？

47 ：デフォルトの名無しさん：03/04/03 01:17

>>45
EJBが目指しているのもたぶんその辺。
ObjectStore等のODBもそんな感じ。
でもどれもこれも不完全で不満だらけなのが現状。

48 ：デフォルトの名無しさん：03/04/03 04:07

正直、DB周りは直接SQL書くのが一番手っ取り早い。
今時、SQL知りません、わかりません、かけませんなんてやつ居ないでしょう。

49 ：デフォルトの名無しさん：03/04/03 04:20

Oracleなどが全部Javaでできていれば楽なんだよな

50 ：名無しさん＠Ｅｍａｃｓ：03/04/03 04:33

そもそもEJBが・・・っていう話が
でてキソウデ怖いんですが。

51 ：デフォルトの名無しさん：03/04/03 08:51

> 今時、SQL知りません

ベンダ固有の瑣末なテクが必須っぽいので手を出しかねてます。

52 ：デフォルトの名無しさん：03/04/03 12:22

WebObjectsに含まれてるEnterprise Object Framework使うと、
TorqueやらJDOやらの中途半端なマッピングライブラリが赤子のように
感じる。売り物だけど安いし。
SQLなんか書く必要無し。RDBのスキーマ情報を自動でブッコ抜いてきて、
クラスにマッピングされたものと、アクセスに便利なメソッドを自動生成。

しかし知名度も低くツブシが効かないという罠。
シロウトにはオススメできない。

53 ：デフォルトの名無しさん：03/04/03 12:59

>今時、SQL知りません、わかりません、かけませんなんてやつ居ないでしょう。
sqlなんてselect,insert,update,deleteくらいしかないもんな。
やりたい事がわかってれば、あとはリファレンスでも見れば
さくっとSQL文が書けるよ。

54 ：デフォルトの名無しさん：03/04/03 13:49

そもそもJavaとは速度が足りない状況になったら
よりよいハードを買ってくれというものだから、
パフォーマンス云々は関係ないんだろな。

55 ：デフォルトの名無しさん：03/04/03 13:59

>しかし知名度も低くツブシが効かないという罠。
>シロウトにはオススメできない。

知名度が低いっていうのは、確かに致命的だよね。
永遠に自分が保守できるはずもないし。

56 ：デフォルトの名無しさん：03/04/03 14:04

>>55
結局、どんなにいいものかよりも多くの人に認知されているかが重要ってことなんだね。
だからオリジナルフレームワークが嫌われる。

57 ：デフォルトの名無しさん：03/04/03 14:20

いつの間にかいいスレができてるな。
このテーマのスレ、待ってたよ。

58 ：デフォルトの名無しさん：03/04/04 00:26

>>43
つこうたよ。認証処理程度だけどね。
IDEとかでコード書きやすくなるのがうれしかったくらいかなぁ・・・。

どっちかっていうとOMクラスよりはデータの吸出しとか
HTMLで定義情報はいてくれたりする事のほうがうれしかった。
RDBに接続してschema.xmlを自動で作ってくれる機能があるのを
最初から知ってればもっと楽になれたんだろうけど。

AntタスクなのでEclipseあたりのIDEとうまいこと統合できるといいのだがねぇ・・。

59 ：デフォルトの名無しさん：03/04/04 03:34

100% Pure Java のRDBMS
これでなんとか・・・・

「Java開発にはJavaデータベースが自然」――米ポイントベース社長
http://itpro.nikkeibp.co.jp/free/NC/NEWS/20030402/1/

60 ：デフォルトの名無しさん：03/04/04 03:46

>>59
Eclipseにシェアを食われつつあるJBuilderの二の舞を踏まないことを祈るばかり。

61 ：デフォルトの名無しさん：03/04/04 11:01

>>60
むしろそのPureJavaRDBMSをただで配布して欲しい

62 ：デフォルトの名無しさん：03/04/04 11:24

>>61
開発用はただで手に入るね。

63 ：デフォルトの名無しさん：03/04/04 11:27

>>59
RDBMSである以上、セマンティックギャップは同じようにあるのだがね。

64 ：デフォルトの名無しさん：03/04/04 12:26

>>61
こういうのもあるが
http://hsqldb.sourceforge.net/
"hsqldb is a relational database engine written in Java"
だそうだ。

65 ：ヽ(´ー｀)ノ：03/04/04 12:41

こんなのあったのか。Torque 面白そう。

>>17
JavaWorld って今月の？ちょっと読んでみまふ…。

66 ：デフォルトの名無しさん：03/04/04 14:21

>>65
4月号に載ってます。
あと技術評論社の「Jakartaプロジェクトテッテイ攻略」にも載ってました。

ただ、少し詳しくいじりたいと思ったらJakartaのページを読むしかないのですが、
余り詳しくは書いてないので、情報収集は結構大変。
Ja-Jakartaにはチュートリアルなどの和訳が有ります。
http://www.jajakarta.org/
http://www.jajakarta.org/turbine/sharing.html

個人的には
・3つ以上のテーブルのJoinがサポートされていない
（2回以上のSQL発行が必要、Viewを使えばよいのかもしれませんが）
・DB依存の書き方は結局残る。（レコードのロックとか）
・普及していない。日本語の資料が少なくTorqueを使える技術者が少ないので将来の保守が心配。

ので、今自分が担当しているプロジェクトで使うのは止めました。

67 ：デフォルトの名無しさん：03/04/04 14:32

http://www5b.biglobe.ne.jp/~ryo-kyo/osu.html

http://my.vector.co.jp/servlet/System.FileDownload/download/ftp/0/279026/pack/win95/game/table/pachinko/sikisai.lzh

68 ：デフォルトの名無しさん：03/04/04 14:33

>>67
LZHに直リンするスクリプト死ね。

69 ：デフォルトの名無しさん：03/04/04 15:29

>>59
どっかで聞いたことあるなと思ったら
ポイントベースってSUNONE4に入ってたのを思い出した
SUNONEインスコしたときに「何だコレ？」と思いつつも
一応、インストした覚えがある
>>62のいうように開発版だとは思うが・・・
ちょっといじってみるかな

70 ：ヽ(´ー｀)ノ：03/04/04 15:48

>>66
サンクス、参考になります。
jakartaのページ見てみましたが、学生なんで業務に使うわけじゃないんで、
現状のままでも大体満足です。ありがとう。

71 ：デフォルトの名無しさん：03/04/04 17:46

Torqueに詳しい人いる？
TorqueってpreparedStatementみたいなSQLのプリコンパイルって
できるの？どうやってやるんすか？
基本的にORB全般的にプリコンパイルはできない？
ただでさえ遅いのに、これできないとつらいなー。

72 ：デフォルトの名無しさん：03/04/04 18:24

>>71
ソースを少し読んでみましたが、たぶんTorqueでは無理だと思います。
毎回Statementを作成し直してるみたいです。

73 ：デフォルトの名無しさん：03/04/04 18:40

>>72
センキュ！
でも、もうTorque使用することになったんだよなー。。。

74 ：デフォルトの名無しさん：03/04/04 20:25

Torqueってどういうときに便利なんですか？

75 ：デフォルトの名無しさん：03/04/04 21:30

>>71-72
たしか、PSなんとかというメソッドがあったきがする。
DocかなんかにPreparedだとコメントしてあった記憶が・・・。
といって使ったことはないので真偽不明でふ。
嘘だったらすまそ

76 ：71：03/04/04 22:08

http://jakarta.apache.org/turbine/torque-3.0.0/apidocs/org/apache/torque/util/BasePeer.html
にdoPSSelectってのがあったよ。
>>74
JDBCのコーディングが簡略化できるのが最大のメリットでは？
ただそれだけと言えば、それだけだな。
SQL書いたほうが可読性がよさそうな気もしないでもない。
あとCreate文の生成とかデータベースの作成とか付属的な機能もあるけど。
ほかに何かあります？

77 ：72：03/04/04 22:54

>>76
TorqueでPreparedStatementを使っているのはBasePeerのdoPSSelectの中だけのようです。
そのメソッドの中でローカルなPreparedStatementを作成して1回だけexecuteQueryしているだけなので
複数回効率的に実行する目的ではPreparedStatement使用していないのかなと思いました。

78 ：72：03/04/04 23:02

一度作成したCriteriaからPreparedStatementを作成して、
効率的に同じCriteriaを複数回実行・・とかは出来ないようです。

79 ：デフォルトの名無しさん：03/04/05 03:10

んー。。。

Criteria.CriterionにもappendPsToとかいうのがあるなぁ。
説明見てもそっけなくてよくわからん。

Criteriaのなかでこれよんだりしてるんだろか。
ソース見る気力ない・・・。

なんか、個人的に使った感触だとCriteriaは使いまわすもののように思えなかったなぁ。
DBに投げた前後で内容が変化したりしてなかったっけ・・・。

効率悪いことこの上ないんだけども・・・。

80 ：デフォルトの名無しさん：03/04/05 04:00

「コネクション張ってSQLをゴリゴリ書いて、投げて受けてクローズ忘れずに・・・」
っていう一連の処理が当たり前になったしなぁ・・・
かといってこういうフレムワーク＆JDOの存在は無視できないし・・・
＞SQL書いたほうが可読性がよさそうな気もしないでもない。
そうなんだよな、少なくとも俺にとってはそう思う
俺の場合はデータベース接続部分を別管理にしてるから
そのほうが見やすいということもある

＞あとCreate文の生成とかデータベースの作成とか付属的な機能もあるけど。
＞ほかに何かあります？
ん？Create文データベース作成は通常でも出来るんじゃないの？
俺昔、MySQL用のSQLのターミナル作ったとき
URLにデータベース指定しないで単に「ｊｄｂｃ:***:mysql」でとめてやったら
Createも、use DataBase名やshow databasesとかもできたよん

81 ：デフォルトの名無しさん：03/04/05 06:25

>>80
76ではないけれど。
>＞あとCreate文の生成とかデータベースの作成とか付属的な機能もあるけど。
>＞ほかに何かあります？
>ん？Create文データベース作成は通常でも出来るんじゃないの？

Torqueの例でいくとXMLで定義した情報をベースにOMクラスをつくるんだけど
同じXMLをもとにDB構築用のSQLを自動生成してDB作りに行ってくれる。
その辺のことを言ってるのだと思われ。

逆にDBを先に構築しておいてそのDBから定義情報を引き抜いてXML生成→OMクラス生成とかね。
データの引き出しなんかもできるから場合によっては環境移行ツールとして使えたりもする。
本筋と外れたとこで便利なんでは？と。

82 ：71：03/04/05 09:18

>本筋と外れたとこで便利なんでは？
普通にJDBCでやるとして、テーブル作成だけTorque使うってのもありだと思う。
テーブル定義書からDB作成なんてツールもPOI、xpathあたりを使えば
簡単にできそう。大幅なコストダウンってわけでもないが、、、

本筋のコーディング部分のところは、今のところメリットは薄そうだね。
学習コストもかかるし、、、
＞かといってこういうフレムワーク＆JDOの存在は無視できないし・・・
同意。雑誌とかでも結構特集されてたりすると、つい良いもんだと
錯覚してしまうよ。この辺の見極めも大事かな。

83 ：デフォルトの名無しさん：03/04/05 10:39

>>80
> ＞SQL書いたほうが可読性がよさそうな気もしないでもない。
> そうなんだよな、少なくとも俺にとってはそう思う
> 俺の場合はデータベース接続部分を別管理にしてるから
> そのほうが見やすいということもある

そうかなぁ？
ひとつのコード中に二つの言語があるということのほうが気持ち悪いと思うけど。
なるべくそういうことは可視性から言っても避けるべきだと思う。
同じようにHTMLの中にＪａｖａのコードが入ることを避けるために、
ＴａｇｌｉｂやVelocityなんかのTemplateがあるわけだし。

84 ：デフォルトの名無しさん：03/04/05 14:03

前のレスにもあったが、結局はプロジェクトに一人
SQLマスターな奴がいればいいんだよな。
速度の問題が出てくると、結局SQL一発でやった方が
ダントツに速い場合がでてくるし。

85 ：デフォルトの名無しさん：03/04/05 16:37

>>83
言語内言語だから正規表現みたいなもんじゃない？

正規表現をJavaのメソッドで構成したら、それは可読性が
高いと言えるんだろうか？

86 ：デフォルトの名無しさん：03/04/05 16:43

>>82
うちの職場では、ExcelにDBの定義書を書いて
スクリプト一発でsqlに変換してる。

87 ：デフォルトの名無しさん：03/04/05 17:01

>>86
オレはスクリプトじゃなくて、た
VBAでさらにテーブル生成までを作った。
（外部キーやPKも）
だけどERwinがあればERwinが一番いい。

88 ：デフォルトの名無しさん：03/04/05 18:52

>>82
>普通にJDBCでやるとして、テーブル作成だけTorque使うってのもありだと思う。
うちは結局これで、ほとんどOMクラスは使ってなくて、
直接SQLを書いてTorque経由で投げてる感じ。
ConnectionPoolの管理とか考えてないのでそれだけでも楽っちゃ楽。

>>83
最近思うんだけどタダ単にマークアップ付き言語が読みづらいだけなんじゃなかろか。
慣れなのかもしれないけど・・・。
少なくとも一般的なプログラミング言語の書式と混在し得ないような気がする。
Javaの中のSQLはうざいけど、流れをそのまま読めるし。

>>86
>>87

俺、自マシンからは直接通信できないネットワーク(要するに客先なんだけど)に
開発環境を構築しなくちゃならないことがあった。
Telnet等でいくつかホストを経由しないと接続できない。

まぁレアケースなんだろうけどTorqueのおかげでローカル環境で作ったものを
むこうで再構築するのが割と楽になったよ。

89 ：デフォルトの名無しさん：03/04/05 19:53

SQLってそんなに学習時間かからんよな
まあ、問題なのはソコではないとは思うのだが・・

90 ：デフォルトの名無しさん：03/04/05 20:06

ポーティングの問題もあるね。
地獄を見た事の有る奴、結構いるんじゃない？

91 ：デフォルトの名無しさん：03/04/05 20:25

>>90
そんな恐ろしいんですか？
全然知らんけどっていうかポーティング自体知らんゴメン

92 ：デフォルトの名無しさん：03/04/05 20:45

JavaでのSQL直書は流れがそのまま読めるので、確かにメリット。

だけど実行してみないとケアレスみすすら分からない。

93 ：デフォルトの名無しさん：03/04/05 21:42

>>92
プログラム書く前にSQL実行しない？

94 ：デフォルトの名無しさん：03/04/05 22:46

>>93
簡単な修正なら実行しない

95 ：デフォルトの名無しさん：03/04/05 22:56

DBシステムにおけるAPの本来の目的は
SQLを発行し、DBへのI/Oだから、SQL生成
プログラムとなっても仕方ないのでは？

もしユーザ（オペレータ）がSQLを知っていたら
（熟知していたら）APなんて必要ない訳だし。

DBシステムなら、必ずしも一つの言語から
アクセスするということでもないし、
（パッケージで単にDBをストレージとして
見るなら別だけど）
言語別にDBアクセスの方法を覚えるの
もなんだかなぁとも思える。

WEBにしてもそう、最終的にはHTML
（やJavascript）で表現するから、
HTML生成がゴールとなってもしょうがない。

96 ：デフォルトの名無しさん：03/04/05 23:04

>>94
おれは、修正云々じゃなくて、
>（プログラムを作って）実行してみないとケアレスみすすら分からない。
ということに答えたんだけど．．．
もし、（最初にSQL実行）してないのなら
まず目的のSQLを書いて実行してから
プログラム製造することを勧めるよ。
そうすれば、ミスもわかるよ。

97 ：デフォルトの名無しさん：03/04/05 23:17

>>95
そうなんだけど、>>92の言うように動的SQLや動的HTMLはコンパイル時点では
ケアレスミスさえ発見できないという問題があるから、そういった部分をTorqueや
JSP+タグライブラリなどで局所的、静的に正しさを保証できる範囲に押し込めて
おいて、あとの全てはJava言語の世界で解決しようという思想なんじゃないかな？

98 ：デフォルトの名無しさん：03/04/05 23:41

>>97
>コンパイル時点では
>ケアレスミスさえ発見できない
なつかしい...PowerBuilderという
開発ツールは、埋め込みSQLでも
コンパイル時点でエラーが分かった。

だけど、そういう仕様だと、
コンパイル時点でDBに接続しておかないと
SQLエラーか分からないし（そうだよね）、
接続してないと、ワーニング出まくった
けど、それでもいい？
確かにSQL解析は便利だったけど、
プログラム書くときはそっとしておいて
欲しいと思ったのは贅沢だったかな。

99 ：デフォルトの名無しさん：03/04/06 00:06

>>98
TorqueやWebObjectsはコンパイル時にいちいちSQLを投げたりしないよ。スキーマ定義
(と各DBMS固有のSQL方言についての知識)さえ持っていれば「エラーにならないSQL」を
生成することは可能だし、そうしょっちゅうスキーマが変更されるわけじゃないから、常に
最新の情報をリアルタイムで取得する必要はないと思うけど。
まぁフリーフォーマットの埋め込みSQLの正しさをチェックするには、実際にDBMSに
投げるか、同等の構文解析エンジンを持つしかないんだろうけど。

100 ：デフォルトの名無しさん：03/04/06 01:03

>>90-91
あるベンダのDBからほかのベンダのDBに移行するような場合の問題だよね
たしかにちょっと特殊なことをやろうとするとすぐ面倒なことになりそうだ

101 ：デフォルトの名無しさん：03/04/06 02:47

最終的にはJDO準拠のものか、EJBのCMPに落ち着くような気がする。

102 ：デフォルトの名無しさん：03/04/06 03:02

そうだね。

103 ：デフォルトの名無しさん：03/04/06 03:04

JDOって始めて知った。有名なの？

104 ：デフォルトの名無しさん：03/04/06 07:05

微妙な問題だな　もれのちょっと思いついたこととしては

* 何十年後かはSQLは無くなってXMLにおけるDOM API, みたく、言語を超えた共通のRDBデータ取り出し用APIが開発される。
* 現状では、自前でその特定のアプリに特化したSQL生成プログラム・フレームワークをプログラマが作るのがいい（シンプルにいこう）

105 ：デフォルトの名無しさん：03/04/06 13:21

>>103
全然有名じゃ無いから知らなくて良し

106 ：デフォルトの名無しさん：03/04/06 21:04

RDBである必要は全く無いんだがな。
smalltalk+OODBが最強。

107 ：デフォルトの名無しさん：03/04/06 23:50

あるクラスに対応するテーブルが二つあります。
例えば「商品クラス」があって商品名や説明文の
インスタンス変数を保持していたとします。日英の
バイリンガルな仕様で、「商品日本語テーブル」と
「商品英語テーブル」がDB内にはあります。

Item item = 生成メソッド(itemId, language);
みたいな形で、商品オブジェクトを取り出したいのですが、
Torqueで実現できますでしょうか？

もしTorqueでは出来ないとすると、他のツール、あるいは
CMPで実現することは可能なのでしょうか？

108 ：あぼーん：03/04/06 23:50

　　 ,.´ / Vヽヽ
　　　 ! i iﾉﾉﾘ）) 〉
　　　 i l l.´ヮ｀ﾉﾘ　＜先生！こんなのがありました！
　　　 l く/_只ヽ　　　
　　|￣￣￣￣￣|
http://saitama.gasuki.com/koufuku/

109 ：デフォルトの名無しさん：03/04/06 23:54

>>107
そういうのをやるためにこのスレの話題にでてくるモノたち
があるわけですが。

110 ：デフォルトの名無しさん：03/04/07 05:13

>>106
漏れは保守的なので Ruby/DBI でいいです。

111 ：デフォルトの名無しさん：03/04/07 21:16

MySQLの全文検索機能を使いたいんだけど、そういうDB依存な物も
Torqueから使えるの？

112 ：デフォルトの名無しさん：03/04/11 23:31

Torqueの「sql2xml」機能を使えている人はいますか？
Antで実行すると、いつまで経っても処理が終わらない。
たった人のテーブル定義でさえも。
なぜ？

113 ：デフォルトの名無しさん：03/04/14 03:44

>>112

やったことないけど
SQLでテーブル作ってしまってjdbcタスクでとりだすというのではいかんだろうか。

TorqueのAnt使う処理っていろいろ配慮が足りてなくて、
いつも今ひとつ痒いところに手が届かない感じ。
もうちょっと手を加えるといいのだろうけど・・・。

114 ：山崎渉：03/04/17 15:30

（＾＾）

115 ：デフォルトの名無しさん：03/04/17 21:00

保守あげ

116 ：デフォルトの名無しさん：03/04/17 22:20

OracleだとBC4JとかToplinkとかでO/R Mappingを実現している

*BC4J
http://otn.oracle.co.jp/cgi-bin/otn/auth_r.cgi?path=/download/products/jdev/htdocs/j2ee_with_bc4j/j2ee_with_bc4j.html
http://otn.oracle.co.jp/cgi-bin/otn/auth_r.cgi?path=/download/products/jdev/htdocs/jdev_wp_bc4j/bc4j.html
## 日本語:要OTN会員ID

http://otn.oracle.com/products/jdev/htdocs/j2ee_bc4j.html
http://otn.oracle.com/products/jdev/info/techwp20/wp.html
# 英語、OTN会員でなくても見られる

*Toplink
http://otn.oracle.com/products/ias/toplink/content.html
# 英語

117 ：山崎渉：03/04/20 03:13

　　 ∧＿∧
　　（　　＾＾）＜ぬるぽ（＾＾）

118 ：山崎渉：03/04/20 03:47

　　 ∧＿∧
　　（　　＾＾）＜ぬるぽ（＾＾）

119 ：デフォルトの名無しさん：03/05/02 19:12

保守だゴルァ

120 ：bloom：03/05/02 19:13

http://homepage.mac.com/ayaya16/

121 ：.：03/05/10 12:28

122 ：デフォルトの名無しさん：03/05/11 12:55

最近のStruts関係の本を読んでるとOJBつかってる本が多いようだ。

うーん、でも今後はJDOで落ち着きそうだね。
今後たてつづけにJDOの本がでるし。
オライリーのJDOの本はそこそこよさそうだね。洩れも注文したよ。
http://jdocentral.com/JDO_Books.html

123 ：デフォルトの名無しさん：03/05/11 12:58

オライリーのJDO本は、JDO作者(Craig Russell)が書いてる本だから買いだね!
http://www.oreilly.com/catalog/jvadtaobj/

124 ：デフォルトの名無しさん：03/05/11 14:47

>>122
その本、前から気になっててサンプルチャプターを
読みました。英語が苦手というわけではないのだけど、
内容が難しくて買うのを断念しました。

125 ：デフォルトの名無しさん：03/05/12 19:13

JDOがなかなか普及しないのは、フリーで使えるJDO実装がないから？

126 ：デフォルトの名無しさん：03/05/12 23:54

うん、きっとそのとおりだと思う＞フリーのJDO実装

127 ：デフォルトの名無しさん：03/05/13 00:24

商用だといくらくらいするんだろう。
5,000円くらいなら払ってもいいよ。

てか、シェアが高そうなJDO実装って何。
どこで調べればいいの。

128 ：デフォルトの名無しさん：03/05/13 12:13

Torqueは割と日本語記事も時々見かけるんだけど、
Castor, OJB, Hibernateあたりを比較して使ってみたﾔｼはいますか？

将来的にJDO/CMPで落ち着くのはいいんだけど、
こちとら三ヶ月先で動くモノを構築することを考えないと
いけないんで……。

129 ：デフォルトの名無しさん：03/05/13 13:08

>>128
日本語記事を抜きにしても、Torqueが使用方法を学ぶ上では
楽だった。

130 ：デフォルトの名無しさん：03/05/13 13:13

>>128
CastorJDOを仕事に使った。
俺が調査した時点では、Torqueはガラクタの寄せ集めみたいで
とても使えるシロモノではなかった。

131 ：デフォルトの名無しさん：03/05/13 13:38

CastorはXMLマッピングはJAXBよりいいと思ったが、JDOは・・・。

132 ：デフォルトの名無しさん：03/05/13 14:33

>>127
ここで調べろ
http://jdocentral.com/

133 ：128：03/05/13 15:26

>>129,130,131
参考になります。いまはTorqueはちょっと措いといて、
いま、Castor/OJB/Hibernateを調査してます。
KickStartとかTutorial程度を見る限りでは、
マッピング用XMLの書き方としては、
Hibernate >>> CastorOJB(どっちもどっち)
という印象なのだけれど、そんなことないのかな。

XDocletが対応してくれてたり、やEclipseでのプラグインがあったり、
というのも助かるので、Hibernateに惹かれているのだが、
このスレ見てる人的にはどーでしょう？

134 ：　：03/05/13 16:11

hibernateはtorqueよりはわかりやすい。
eclipse pluginのhibernatorを使おうとしてDBにconnectすると
java.lang.IllegalArgumentException: Path must include project and resource name: /プロジェクト名
とか言われて動かない。
DBの接続設定は多分間違ってないと思うんだけど、原因わかる人いますか？

135 ：134：03/05/13 16:44

hibernate勉強中です。

ところでhibernate query languageってなんだ
SQLよりわかりにくいぞ

136 ：128：03/05/13 17:28

XMLマッピングファイルの比較(?)が終わって、
クエリのところに来たんですが、
HQL(w って、独自仕様？
FAQを眺める限りだと
「SQLとそんなに変らないから安心して使ってね」と言っているように
みえるけれど、独自仕様なことに変りはないんよね？

これは実際の仕事プロジェクトで導入するには
抵抗に合いそうな予感……。

私ももうちょっと勉強してみます。

137 ：130：03/05/13 17:43

>>136
参考までに、CastorJDOもOQLっていう独自の言語でオブジェクトを
fetchする必要があります。

SELECT o FROM com.example.package.Person o WHERE id = 1

こんな感じ。

138 ：128：03/05/13 17:45

>>137
仕事で使うにあたって、
プロジェクトや顧客の抵抗にあったりしませんでした？

139 ：130：03/05/13 17:59

>>138
自社プロダクトでしたので特に問題は無かったです。
ただ、マッピング＆クラス作成がほぼ手作業になってしまって
あんまり工数削減につながらないので、CastorJDOを使うのは
これっきりという感じ。

Hibernateはよさそうね。

140 ：128：03/05/13 18:03

>>139
導入に抵抗が無かった、ってのはいいですね。
クラスはともかくもマッピングが手動でしかやれない、
(もしくはツールを開発する)となると工数的なメリットは
キビシイっすね。
Castorもそうだし、OJB(の現状?)もそうなのかな。

ドキュメントもちゃんとしてそうなので、
ちょっとHibernateを実コードベースで調査したいと思います。

141 ：デフォルトの名無しさん：03/05/13 21:41

Hibernate は何て読めばいいのでしょうか？

142 ：デフォルトの名無しさん：03/05/13 22:10

はいばねーと、でええんでないか
http://dictionary.goo.ne.jp/search.php?MT=hibernate&kind=ej
ノートPCのハイバネーションと意味的には似たようなもンだろう

143 ：U ◆CZtFsGiu0c ：03/05/14 01:01

>>137
OQLは「独自言語」ではないと思うが。
もしそれがOMGで既定されたOQLと違うのであれば別だけど。

144 ：デフォルトの名無しさん：03/05/14 09:41

>>143
http://castor.exolab.org/oql.html
ODMG3.0仕様のサブセット + 独自方言だそうな。
まあ、どこのSQLも方言はあるしな

145 ：デフォルトの名無しさん：03/05/14 10:52

OJB使ってるﾔｼはいますか？

146 ：デフォルトの名無しさん：03/05/14 13:01

Hibernateの1.2系と2.0系は大きくどこが変わっているのでしょう？
今から学びはじめるとしたらRC2の段階の2.0系でしょうか。

147 ：デフォルトの名無しさん：03/05/14 15:29

EJBつかえばいいじゃん。

148 ：130：03/05/14 16:40

>>147
EJBじゃオオゲサなプロジェクトだってあるしね。

149 ：デフォルトの名無しさん：03/05/14 16:43

((≡゜♀゜≡))いいよ～
http://homepage3.nifty.com/coco-nut/

150 ：134：03/05/14 16:47

>146

パッケージ名が変わってたり

Hibernate.createDatastore().storeClass(Foo.class)..buildSessionFactory();

が

new Configuration().addClass(Foo.class).buildSessionFactory();

にかわってたり、ドキュメントがないのが痛い。

151 ：128：03/05/14 18:01

>>150
いま、1.2.3のドキュメントを攻略中なんだけど、
やっぱり2.0にトライするのに
http://hibernate.bluemars.net/68.html
だけだとツライ？

152 ：デフォルトの名無しさん：03/05/14 18:54

おまいらｳﾞｧｶだな。なんでデファクトスタンダードのSunJDOを使わないんだ?
オライリーからも本がでてるし(しかも米国では売れてる)、教材にはもってこいじゃないか。

153 ：デフォルトの名無しさん：03/05/14 19:23

オープンソースかフリーの実装でコレ！ってのはあるの？
いまちょっとぐぐって見つけたもの:
http://tjdo.sourceforge.net/
他には？

154 ：デフォルトの名無しさん：03/05/14 22:05

Torqueでレコードレベルのロックを掛けたいときはどうすればいいの？

155 ：デフォルトの名無しさん：03/05/14 23:49

XORM(クソームってなんかフリ鯖を思い出すな。)
http://xorm.org/

156 ：デフォルトの名無しさん：03/05/15 00:03

「Programming Jakarta Struts」、
「Professional Struts Application」ではOJBをつかってるね。
もちろんOJBもJDOAPIサポートしてるよ。

157 ：146：03/05/15 00:45

>>150
ダウンロードすると中にドキュメント入ってたよ。
2.0 beta 5のやつだけど。

158 ：デフォルトの名無しさん：03/05/15 03:00

>>153
TJDOはいまあるフリー実装の中では、多分一番いい出来だと
思う。(ドキュメントを読む限りで。ソースを見たわけではない。)
ただ、アプリケーションサーバで使う場合にDataSourceを
JNDI経由で取って来れないのが、オレの中では×。

>>156
OJBはJDO APIが使えるだけで、マッピングは独自のものだよね？

Hibernateは確かに惹かれるものがある。が、JDOではないのが
ちょっと気になる。ただこのままフリーで優れたJDO実装が当分
出てきそうもないのなら、Hibernate使うしかないじゃんと
自分を説得しようとしている。

Torqueは使ってみたけど、BaseXXX、BaseXXXPear、XXXPearとか
たくさんクラスが生成されるのがイヤになった。ちょっと複雑な
Selectをしようとすると、途端にCriteriaの生成が難しくなる。

159 ：デフォルトの名無しさん：03/05/15 10:42

XORMのFeaturesをざっと見たんだけど、
これも現状だとコンテナJNDIからのDataSource利用は
できないのかな？

160 ：134：03/05/15 10:42

>157
ありゃほんとだ。ホームページさがしてたよん。
で2.0のドキュメントみたけどサンプルコードがいっぱいのっててｲｲ！
なので1.2は捨て。

161 ：128：03/05/15 10:49

>>160
をを。ほんとうだ。昨日一日1.2のドキュメント読んでたよ....

162 ：デフォルトの名無しさん：03/05/17 00:08

いま、OJBのページを翻訳しながらいろいろためしてるところ。

163 ：デフォルトの名無しさん：03/05/17 03:18

>>162
OJBの翻訳サイトあるよ。http://www.terra-intl.com/jakarta/ojb/

わいのマイブームはStrutsとOJBを連係させることかな。
いいチュートリアルサイトがあるべ。英語だがね。
http://www.robertoghizzioli.it/jcomm/jcomm_tutorial.html

164 ：デフォルトの名無しさん：03/05/17 11:22

>>163
それはさすがにしってる。
でも、チュートリアルとかは翻訳されてないから、そことかね。

165 ：デフォルトの名無しさん：03/05/17 11:26

エロ嫌いならクリックしなきゃいいじゃん。
http://accessplus.jp/staff/in.cgi?id=11141
ﾌﾟﾆｭ　（ﾟ∀ﾟ）σ)´Д｀)

166 ：デフォルトの名無しさん：03/05/20 15:47

torqueよりもOJBを使うべき理由ってどんなのがありますか？

167 ：デフォルトの名無しさん：03/05/20 18:24

数ヶ月前の月刊JavaWorldに、
OJBもTorqueベースで開発されている、みたいなことが
書いてあったんだけど、そうなんですか？

自分で確認しようと思ったんだけど、Torqueがわからないので……

168 ：デフォルトの名無しさん：03/05/20 18:26

まゆ13歳
http://members.tripod.co.jp/nichkirai/index.htm

169 ：デフォルトの名無しさん：03/05/20 19:20

>>168
それ笑えるな
本当に女で１３歳だったらなかなかすごいかも知れんなｗ

170 ：デフォルトの名無しさん：03/05/20 22:23

>>167
OJBは足周りにTorque使ってるよ。

171 ：デフォルトの名無しさん：03/05/20 22:26

Torqueはクラス作成&データベース作成を自動でやってくれるからゼロから作るときにはTorqueが便利。
OJBはクラス作成もデータベース作成(内部テーブルはTorqueを利用)も自分で作るから自由度が高い。
後で変更するときに簡単に修正できる。

＞OJBもTorqueベース
OJBはauto_incrementを利用するときに内部テーブルを作るんですよ。
そのときにTorqueを利用します。

172 ：デフォルトの名無しさん：03/05/21 15:52

Torqueは外部結合は出来ないんですか？？

173 ：172：03/05/21 16:12

自己レス。できないんだってサ

174 ：デフォルトの名無しさん：03/05/21 16:27

正規化しまくって何でもかんでもJOINで取得するようなテーブル定義だと
CastorでもTorqueでもHibernateでも、いまいち馴染まない気がする。

この種のデータバインド機構を使うなら、ある程度割り切らないと
駄目なのかねえ。

175 ：172：03/05/21 17:43

内部結合は出来たので、とりあえず書いておきます

顧客を表す以下のテーブルがあるとします。

create table employee (
id numeric,
name varchar;
manager_id numeric
);

idはキーであり
nameは名前
manager_idはマネージャのid(自己参照)が入る

//片方のテーブルにe2というエイリアスを設定する
criteria.addAlias("e2", EmployeePeer.TABLE_NAME);
//idが1であるレコードを検索対象とする
criteria.add(EmployeePeer.ID, 1);
//managerのidが1であるレコードを検索対象とする
criteria.add("e2.id", 1);
//自己結合の設定
criteria.addJoin(EmployeePeer.MANAGER_ID, "e2.id");

176 ：デフォルトの名無しさん：03/05/21 22:05

外部結合するのなら、直接Toroqueをつかうより
Viewをつかったほうがパフォーマンス的にもいいと思うんだが。

177 ：172：03/05/22 14:00

Viewを使って試験したのですが
あるテーブルを結合させる処理を1000回行ったところ
JDBCを直接操作する処理では平均で1.8秒かかったのに対し
Viewを使用したTorqueでは2.3秒
Viewを使用せずにTorqueの機能を利用して結合させたところ3.4秒でした。

178 ：デフォルトの名無しさん：03/05/22 14:22

>>174
哀しいけれど、O/Rマッピングツールの目的は
ObjectをRDBにどれだけ楽して格納するか、であって、
RDBレコードを如何にしてObjectとして扱うか、が目的では
ないんだよね。

なので、行儀正しく正規化されたDBありき、だと
ツールの特性を梃子にした生産性の向上は実現しづらい。

なにごとも適材適所。
照会系は「JDBC for Reading」で割り切るのもテかな、と
あらゆるオブジェクトを透過的に操作できるのは
理想的だけれど、スループットを考慮にいれると、
現状ではなかなかそうもいかないですよね。

切り分けの境界をどこに置くかがなかなか難しいんだけれど、
そこをきちんと定義できてこそエンジニアかな、とも思う。

私もここらへんはまだまだ手探りなので、
このスレの意見はとても参考にさせてもらってます。

179 ：172：03/05/22 14:57

JDBC+Viewの試験もしてみました。
Torqueの場合はかなり高速化されたので、こちらはさぞ早いだろうと想像しましたが
何と平均が1.8秒→2.1秒と0.3秒もダウン

180 ：デフォルトの名無しさん：03/05/22 22:04

>>179
どのようなスキーまでどのようなSQLを実行したかによってスピードなんて変わってくるからね。
１０００件で２秒前後ならそんなもんでしょ。

そこまでクリティカルなスピードを求められるならTorqueやJDBCをじかに呼ぶより
EJBを導入することを考えたら？

OJBならEJBと連携できそうだし。

181 ：172：03/05/22 22:56

>>180
EJBも勉強してます。

とりあえず今は、お手軽にDBを操作する方法は無いかな～と思ってて。
前は「俺実装」のライブラリを一生懸命作ってたんですが、
そんなのより世の中に有る物を使ったほうがいいかなって。

182 ：デフォルトの名無しさん：03/05/23 00:52

だれかExpressoのO/Rマッピング使ってる方いますか?

TorqueとOJBを試してみたので(個人的にはOJBが簡単で好き)
今度はExpressoを試してみようと思います。

183 ：デフォルトの名無しさん：03/05/23 02:28

WizOnline開発中！プログラマ緊急募集（C,Java）
http://219.96.231.242/wizonline/
２ｃｈスレ
http://game3.2ch.net/mmominor/dat/1053536167.dat

184 ：デフォルトの名無しさん：03/05/23 18:10

OJBですが、tutorial1を試してそれからPostgreSQLで
tutorial1のサンプルアプリを動作さすところまで実験しました。

でも、最初からアプリを作成する方法がよく分かりません。
PostgreSQLで動かそうと思っても、最初にOJB_HL_SEQテーブルが無いとかのエラーがでるし。
「何そのテーブル？」って感じでした。

一から作成しているチュートリアルって何処かに無いですか？？

185 ：デフォルトの名無しさん：03/05/23 21:20

>>180

＞そこまでクリティカルなスピードを求められるならTorqueやJDBCをじかに呼ぶより
＞EJBを導入することを考えたら？

EJBってJDBC直より速いか？

186 ：デフォルトの名無しさん：03/05/26 03:14

>>185
それは断じてないでしょう。

187 ：デフォルトの名無しさん：03/05/26 08:38

>>185 >>186
EJBもJDBC使ってるのですが

188 ：デフォルトの名無しさん：03/05/26 16:21

>>187
だから、JDBCを直接つかう場合よりもオーバーヘッドが増えて遅くなるって話だろ。

189 ：172：03/05/26 16:40

OJBも実験してみました。
SELECTを試したのですが
idとnameを持つテーブルを1000回selectする実験では

JDBC:1311ms
Torque(BasePeer#doSelect()を使用):1505ms
Torque(BasePeer#doPSSelect()を使用):914ms
OJB(PersistentBroker使用):3625ms

と、言う結果でした。
なぜかTorqueのdoPSSelectが最強です。
OJBはリフレクションを多用しているせいか、かなりの低パフォーマンスですね。

190 ：172：03/05/26 16:44

ただ、OJBはTorqueよりもエレガントなコードが書けそうです。

191 ：172：03/05/26 16:45

あと、JDBCはPreparedStatementを使用しました。

192 ：デフォルトの名無しさん：03/05/26 23:33

EJBはキャッシングがあるから、場合によっては生JDBCより早いんでないの?
複雑なアプリでどの程度効用が得られるかはかなり疑問だが。

193 ：山崎渉：03/05/28 12:43

　　　　∧＿∧
ﾋﾟｭ.ｰ　(　　＾＾）＜これからも僕を応援して下さいね（＾＾）。
　　＝〔~∪￣￣〕
　　＝ ◎――◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉

194 ：デフォルトの名無しさん：03/05/28 14:56

保守

195 ：デフォルトの名無しさん：03/05/28 17:50

>>188
全体的な視野で JDBC直と EJB(CMPEntityBean) とのパフォーマンス比較を
すべきだと思うよ。自分でJDBC直でちまちま実装するより、EJBコンテナに
任せたほうがより効率的に処理することもあるんでないの?

196 ：デフォルトの名無しさん：03/05/28 21:33

>>195

JDBC for Readingパターンっていうわけじゃないけど、
通常はEJB(EntityBean)を使いつつ、
性能がほしいときに、DAO(JDBC直)って使い分けてる。

197 ：デフォルトの名無しさん：03/05/29 15:54

JDO vs Hibernate
http://www.javalobby.org/thread.jsp?forum=61&thread=7836

198 ：デフォルトの名無しさん：03/05/30 16:51

漏れも>>184同様、Tutorialの次に何をすればいいのかわからん...。
自分のプロジェクトはどう作っていけばいいのかの話の説明がないような?

199 ：デフォルトの名無しさん：03/06/14 10:35

すいません、皆さんヒントだけでも教えてください

簡単な例で説明します。
社員の出勤表があります。
テーブル名はもちろん社員番号で割り振っています
カラムは[日付、その日の成績、出勤時間、退勤時間]
（実際には、10項目ぐらいカラムがあります）
となっています。
で、当然同じ形式で社員の人数分あるわけなんですが
このテーブル全てをマッピングしようと思い、
トルクとか使おうと思ってるんですが、
テーブル名ごとにマッピングのクラス書かないといけないんですかね？
いままでJDBC直のばあい、入力した社員番号から
テーブル読み出せるんですが
トルクとかのラッピングツールはテーブルごとに
クラス作りますよね？社員全部のクラス全部作らないといけないんでしょうか；

あとは、テーブルの合成も考えました。カラムは今までのやつ＋社員番号が
入るカラムを追加して（重複許す）全部一つにまとめるって言うやり方です

でもできれば社員ごとに一個ずつテーブル設けたいのです
なんか、うまいやり方ありませんか？

200 ：184：03/06/14 11:13

>>198
むやみやたらにいろいろと実験したら何となく使えるようになったヨ。
でも今のプロジェクトではC#を使っている罠（ｗ

201 ：デフォルトの名無しさん：03/06/14 11:15

>>199
テーブル設計が激しく間違っていると思う

202 ：デフォルトの名無しさん：03/06/14 11:16

>>199
社員ごとにテーブルがあるってこと？

それがそもそもありえない。
RDBMSの勉強からやりなおした方がいいんじゃないの？

203 ：デフォルトの名無しさん：03/06/14 11:28

>あとは、テーブルの合成も考えました。カラムは今までのやつ＋社員番号が
入るカラムを追加して（重複許す）全部一つにまとめるって言うやり方です

このテーブルを最初っから作ればいいんじゃないの？
粗度が細かすぎるよねその設計だと・・・・

204 ：デフォルトの名無しさん：03/06/14 11:33

>>201-203
レスありがとうございます
すいませんDBの勉強しなおしてきます
ちなみに私が設計したわけではありません;;
なので、とりあえずデータ構成の変更を要請してみます
ありがとうございました

205 ：デフォルトの名無しさん：03/06/14 12:47

>>204
だれの設計かは知らんが、もし先輩社員の設計ならば
職場を変えたほうがよいかも。

206 ：デフォルトの名無しさん：03/06/14 13:00

>>205
ありがとうございます

いちおう、再設計を任せてくれそうになりました
社員番号と日付を複合キーにして>>203の言うようにしたいと思います
ただ、テーブルの行数が多くなりますが
ｄｂの設計って言うのは何千行でも何万行になったとしても
こういう作り方をした方が良いのでしょうか？
聞いたところによると、最初の設計者が
あまりひとつのテーブルに行が多いとダメ見たいなことを言ったらしくて
そういう使用になったそうです
いちおうオラクル６なんですがオラクルなら何千何万行でもOKですよね

207 ：あぼーん：あぼーん

あぼーん

208 ：デフォルトの名無しさん：03/06/14 13:09

>>206
まずはその最初の設計者を殺しましょう。

Oracle（というか最近のフリーのRDBもふくめて）でシステムを組んでて何千何万程度のレコードを心配するなどありえない。

209 ：デフォルトの名無しさん：03/06/14 13:19

>206
君の会社すさまじくレベル低いよ。大丈夫か?
DB設計の初心者本で正規化について勉強しとけ。

技術力低い分、特定業務に特化しているのだろうから、そのあたり盗んどけ。
自分の思い通りにプロジェクトを進められるのも、
小さな会社の利点だから、いろいろ挑戦してみな。
ある程度力つけたら転職しよう。

210 ：デフォルトの名無しさん：03/06/14 13:53

>>209

言い忘れていましたが、私の会社は基本的には
そういう開発の会社じゃないんです
つまりその、皆はっきり言ってプログラミングとかそういうことは
ド素人でして今回私が抜擢されたのもただ単にちょっと知識
あるからという理由です
自社で済むことは自社内でって言うやり方でして・・・
なので、そのプログラム作ったからといって給料とかupされるわけではありません；；
実際にはセールスが本業なもので・・・
とにかく、後継に迷惑かけないようにしっかりしたもの作ります
転職ですか・・・プログラマはわたしは無理ですね
ココに質問する時点でセンス無いと思ってますから

211 ：デフォルトの名無しさん：03/06/14 14:09

>>210
逆にそんな立場でTorque使おうって技量に感心。
素直にそう思った。エンジニアじゃないのね。

212 ：209：03/06/14 14:20

なるほど、社内のシステム部の人か。

少なくともRDBの基礎は学んでおいたほうがいい。
あまり良書とは思わなかったが、入門テキストとして、
「データモデリング基礎講座」
http://www.seshop.com/detail.asp?pid=1401

最初からしっかりしたものを作るのは不可能なんで、
何度か作り直すつもりで、気軽にね。

自社で開発するにしても一人ぐらい社外の人を入れないと無意味だと思う。
顧客と開発が近いのは利点だけどね。

213 ：デフォルトの名無しさん：03/06/14 15:31

とりあえず、何かの結果を求める時に、そこに必要な全てがどんな階層(関連)になっていれば
扱い易いか考えてみ。（それを徹底的にやるのが正規化）

[社員の給料]←[社員の特定]←[部署の特定]←[会社全体]

みたいな。簡単で申し訳無いけど。

214 ：デフォルトの名無しさん：03/06/14 15:43

>>211
Javaなら知っていたので「それでよければやりますが？」
といったら、「じゃ、君やりなさい」と言われました
自社のポータルも私作ったんですが
DB関係はまったくの初めてなのでどうなることか・・・

>>212
システム部といっても私一人ですよｗ
そういう部署設けるぐらいの会社なら
最初から外部に頼んでますよきっとｗ
リンク先覗いてみますありがとうございました

>>213
ありがとうございます参考にさせていただきます

215 ：213：03/06/14 15:58

あ、ちなみに一人で作業するとなると、必然的に脳内で「一人会議」とか「一人ミーティング」とか
する事になると思うけど（笑）その時にはきちんと"全体設計"、"DB設計"、"コーディング"とか、
各フェーズを明確に分けて考えた方がいいよ。それぞれの担当になったつもりで。
その方が完成までの期間とかの見積もりも出せるし。

今回の件では、やりたい事は明確になっているんだろうから、とりあえずDB設計が先か？
その設計次第でコーディングの内容も変わるだろうし。

とりあえず、概算見積もりにはいつも10%上積みの方向で上司に報告っと。（笑

216 ：デフォルトの名無しさん：03/06/14 18:18

正直、その技量でTorqueに手を出すと悲惨なことになると思う。

Torque自体のドキュメントやツールがロクに整備されていなかったり
チュートリアルと実際の動作が異なる場面が多かったりなので頑張れ。

217 ：デフォルトの名無しさん：03/06/14 18:35

俺もTorqueはちょっとどうかなーと思う。
まだCastorの方がいいかも。
XMLとの親和性もいいしね。
なんならRelaxerという手もある。

218 ：デフォルトの名無しさん：03/06/14 18:51

ORACLEのBC4Jってどうなんだろ？
JDeveloper高いけど・・・。

219 ：デフォルトの名無しさん：03/06/15 00:14

>>206
なんでOracle6なんだってつっこみはなし？

あと、さすがに数百万行とか数千万行になるようなテーブルとかならデータ量は気にするよ。
でも、こんなの出てくる場面がかなり限られるので気にしないほうがいいね。

220 ：デフォルトの名無しさん：03/06/21 21:39

HYBERNATE使って開発してるんだけど、SQL組み立てて
直接JDBCに流し込んだほうが効率いいんだよなー。
それでもプロジェクトで使うって決まってるから使うんだけどね。
レコードをオブジェクトにして、getsetでデータを加工する。
だから件数が多くなればなるほど処理時間が長くなるし、JVMのヒープも
多めにとっとかないとパンクする。
プログラム組んでるとJavaって感じよりCOBOLって感じがする
COBOLもSQL組み込めるけど、Keyをセットしてデータを取り出すって手法似てる
って意味です。

221 ：デフォルトの名無しさん：03/06/21 22:36

だれが、SQLラップしようとしたのだろう？
SQLと、プログラムのロジックの記述を
うまく組み合わせることが出来ていたのに
なぜわざわざ。。
仕方ないからやってるけどさ、
逆に、カラム増やすことになって困るのは
CMPや、Torqueのほうだってことだよ
俺個人のプロジェクトのとき
頻繁にテーブル構成変えることあったが
SQL生だとすぐに移行できるが
CMPとかだとちょっとね・・・
動き出すまでに、1時間ぐらい躊躇う

222 ：デフォルトの名無しさん：03/06/21 23:03

禿同
漏れもSQLを生成させて実行、その後はResultSet、
もしくはVectorを返して扱った方がいい。
更新系もSQLを生成してExecuteでぶち込む。
そういうメソッドを持ったクラスの方が
テーブルマップドクラスなんかより
よっぽどビジネスロジックに即している。

SQLについては、ビューやストアドを
使ってシンプルにさせることは
追求しなければならないと思うけどね。

223 ：デフォルトの名無しさん：03/06/21 23:23

禿同
だいたい、JavaにおけるDBのラッピングなんて
JDBCドライバで十分だよ
それにいまのJavaプログラマは
環境依存になるととたんに触手を引っ込める
DD書くのも環境依存なDDが必要になると
いやがるな。まあ、それは俺もそうなんだが・・・
あと個人的な意見では、>>222も書いてるように
SQLの使い方、ストアドの使い方その他もろもろの
細かい設計までやれるのはとても興味深い
パフォーマンスも追及できるしさ・・・
まあ、仕事では再利用性などを考えて
クラスの数が多くなってもいいからデザイン優先じゃない？
まあ、仕事だからやってるし勉強するけど
おれは、今のこの現状を少し遠目に見ている

224 ：デフォルトの名無しさん：03/06/22 00:11

実は俺もうすうすそう思っていた。
DBとオブジェクトのマッピングは、所詮
不毛な努力なんじゃないかと。
そういいつつも、何かうまい方法があるんじゃないかと、
つい方法を追ってしまうのだよねえ。

225 ：デフォルトの名無しさん：03/06/22 01:29

だいたい、DB相手のEJBやってるとさ　バカらしくなってきちゃう
だって、そのままSQL発行すりゃーいいのに
わざわざ、オブジェクトにsetで格納して
向こうに届いたら、getでとりだしてデータベースにインサート
どう考えても二度デマだろ？
向こうで取り出しやすいようにオブジェクトの
構造もワザワザ考えなきゃならんし・・・
DBからデータ取り出すときなんて、
余計なカラムまで取り出したくないのに、
プログラム的には一度に取り出したほうが楽なので
不要なデータも取り出してしまう・・・
しかも、コレクションで帰ってくりゃ
イテレータで取り出し＆キャスト

SQLなら他のUtilクラスにPreparedStatementのSQL文を
static フィールドで保持しておいて置けば
意外にコードはすっきりだ
ストアドもそう。
だいたい、SQL直ってそんなに難しいか？

226 ：デフォルトの名無しさん：03/06/22 01:35

まあ、一人で開発している分にはSQLを直接書くのもいいだろうな。

227 ：デフォルトの名無しさん：03/06/22 01:38

>>189

無意味な事してんな（ｗ

インデックスの張り方とかテーブルの列の順序とかstmt、rsのCloseのタイミングとかは？

228 ：デフォルトの名無しさん：03/06/22 02:23

>>226
SQL知らない奴らと一緒にやってると大変だよな。

229 ：デフォルトの名無しさん：03/06/22 02:44

SQLなんてどうせ基本しかつかわんだろ？
おれなんてSELECT　UPDATE　INSERT　DELETE
FROM　ORDER　BY　ぐらいしかつかわんぞ
あとは、データとってくればこっちで何とかするやり方だよ
ストアドだってその場その場で本開けば解決できるしよ

230 ：デフォルトの名無しさん：03/06/22 03:32

なんか妙に一理あるな＜マッピング不要論

結局俺もJDBC直でやっているわけだが理由は結局O-Rマッピングがかったるいから。
でも、JDBC直だといまいちだなと思うこともまた事実なわけよ。結局Javaの世界
ではやっぱりObjectで扱っているわけだがResultSetからObjectへの変換および
その逆がうざい。かといってODBはよくわからんし。

231 ：230：03/06/22 03:43

でさ。ふと思うわけよ。理想的なObjectの格納方式ってなんだろうって。
結局

(1)オブジェクトをなんでもかんでも叩きこめる
(2)問い合わせ言語が存在し必要なオブジェクトがひっぱりだせる

の2条件が成立すれば良い訳だ。なんとなくxpath + XMLDatabase + relaxer
でよさげなのが出来そうだな。

232 ：デフォルトの名無しさん：03/06/22 03:46

俺が最初DBのマッピングって聞いたとき
オブジェクト投げたら勝手にインサートしてくれるものだと思ってた
たとえば、JavaBean同様にアクセサのあるクラスで
それに加えて内部に情報フィールド持ってて
たとえばデータソースURIやユーザ名パスワード
（この辺はプロパティファイルから読み込みでも可）
でもって、
#insert(Object obj)
とか何とかやれば、自動で内部のフィールドを取り出して
自分でSQLを吐いてくれるやつだとおもってた・・・

Torqueぐらいのマッピング程度ならいままで書いてますよね皆さん？
SQL文発行は一部のクラスに追いやって
そのクラスに対して
insert(String[],int,int)や
select(String tablename,String columnname)
とか言うメソッド作ったりしてませんでした？
俺にとってはなんの新鮮味もありませんでしたよ

233 ：デフォルトの名無しさん：03/06/22 03:50

>>231
すれ違いかもしれんが
おれ、いまXQueryって興味あるんだけど
XMLデータベースサーバーって
どっかにFreeのやつない？
俺が探して見つけたのは有料なんだよなぁ
いまは、え～と名前忘れたが
＠ITとかで落としたソフトのライブラリ使って
Javaで遊んでいるのだが・・・

234 ：デフォルトの名無しさん：03/06/22 04:28

>>233
XindiceってApacheのXMLプロジェクトじゃなかったっけ。

235 ：デフォルトの名無しさん：03/06/22 04:31

XMLデータベースって、どうやって性能出すんだろ。
挿入と、複数条件検索がコストでかいがするんだが。
インデックスをノードのプライマリキー以外に張ると
エライコトになりそうだし。
XMLデータベースと入っても、ストレージのフォーマット
実装は、XMLとは直接関係無いスタイルにしないといかん
ぽな気がするな。

詳しい方、無知なオイラにおしえてちょ。

236 ：デフォルトの名無しさん：03/06/22 04:46

マッピング不要論が色々と出ているわけだが、
SQL直書きだと、オブジェクト指向のメリットであるところの
ロジックの局所化が生かせないような気がしなくもない。
ユースケース単位でがしがしSQL作っていると、
いろんな機能にSQLが散らばってメンテナンス不能、みたいなことには
ならないでしょうか。
SQL直書き派は、その辺のところどうやって解決してますか。

237 ：デフォルトの名無しさん：03/06/22 05:02

>>235
やっぱインデックスとキャッシュなんじゃない。
あとは問い合わせ言語の最適化とかのアルゴリズムとか。

238 ：デフォルトの名無しさん：03/06/22 07:02

最初は面倒だけど、なれてくると、
あとで拡張するときとかめちゃ便利だよ。
Torqueつかってます。

239 ：デフォルトの名無しさん：03/06/22 08:22

>236に同意。
SQLはプログラムから見ると単なる文字列リテラルでしかないのでロジックとの結合がぜんぜんない。

例えばResultSetから取り出すときに型を間違えてもコンパイラはぜんぜんわからない。
これがマッピングされた環境だとそんなタコミスは即座に判明し、テスト時間も大幅に減らせる。
最悪テーブルの構成が変わったときなど、SQLだとgrep→SQL変更→ResultSet関連変更などなど件数が多くなるほど悪夢のような作業が発生するが、
マッピングされているとその変更の手間は局所的に押さえることができる。

240 ：デフォルトの名無しさん：03/06/22 11:02

（´-`）.｡oO(不要ならばここで述べた理由をいえば上司を説得できるだろうに。。。。。

241 ：230：03/06/22 12:37

>>233
>>234もレスってるがXindiceがFreeで使える。ただXQueryはまだ実装されて
いない模様。

Apache Xindice XQueryはまだサポートされていない模様
http://xml.apache.org/xindice/

Xindice:無料で使えるXMLデータベース
http://www.atmarkit.co.jp/fxml/tanpatsu/18xindice/xindice01.html

>>235
XMLデータベースを使用する時って現状だと性能はあんまり関係ない場合に限
られるんじゃないかと思う。XMLデータである限りその分のオーバーヘッドは
どのみちかかるしな。今のところそれなりのデータ量があるようなプロジェク
トで使う気にはなれないな。

ただ、将来的には面白いと思って見ている。Object<->Relationalの変換を
考えるから色々問題が発生するんだよ。それなら根っこから変換不要のデータ
保持形式を考えてみるのも面白いだろ。

242 ：デフォルトの名無しさん：03/06/22 14:43

>>233
eXistはどうよ

243 ：デフォルトの名無しさん：03/06/22 14:55

（´-`）.｡oO(だからうちは使ってないけど。。。。。

244 ：デフォルトの名無しさん：03/06/22 15:38

「データベースシステム」
を構築しているのか
「Javaアプリケーションシステム」
を構築しているのか
そこら辺の違いだな。

245 ：デフォルトの名無しさん：03/06/22 20:28

SQLゴリゴリ派ですが、
メンテナンス性とかより
学習コストがかかるから避けるっつーのはおかしいかな。
もちろん、プロジェクトメンバー数分ね。

ODB技術全般的にドキュメント類が整備されてないし、
バグもあるだろうし、「なんでできないんだー！」で
結構時間食ったりする。

外部結合とか○○ができないから、そこんとこは
JDBCでよろしくね。なんてことになったら
それこそ、メンテナンス性なんてあったもんじゃない。
実際、システムを保守する人も開発メンバーとは限らないしね。

あと、Strutsほど導入メリットもなく、枯れてないしね。

246 ：デフォルトの名無しさん：03/06/22 22:12

>>245
それはよく分かる。
RDBのオブジェクトマッピングは、まだ設計技術が
成熟していないような気がするので、
うかつにやってしまうとかえってメンテナンス性が落ちそうな気がする。
この分野はまだまだ試行錯誤の期間が続きそう。
なんか、Strutsとか出る前に、Servletに直接ビジネスロジックを
ゴリゴリ書いていた時代を思い出す。
納期がやたらと早いプロジェクトとかだと、導入リスクが高いので、
SQLゴリゴリの方が、メンテナンス性（メンバーのメンテ能力っていう意味でね）
は高いような気がする。

247 ：デフォルトの名無しさん：03/06/23 00:03

.NETのSqlDataAdapter や PowerBuilderのdatawindow のような、
クエリをクラスにカプセル化するような方法は一般的ではないのでしょうか？
そっちのほうがずっと抽象的な扱いができると思うんですが。
そう思って、SELECT文を記述したXMLからResultSetのラッパークラスを
生成するプログラムを作り中。

248 ：_：03/06/23 00:03

http://homepage.mac.com/hiroyuki44/

249 ：デフォルトの名無しさん：03/06/23 00:07

>>247
SqlDataAdapterはとてもじゃないけどカプセル化されてるように見えない。
糞VB再現って感じだなー

250 ：247：03/06/23 00:15

ちょっと知ったかぶってしまいました。
SqlDataAdapter って３日前に知ったばっかりでした。

251 ：239：03/06/23 00:31

>239といいつつ、実はTorqueのCriteriaクラスのタコさ加減にかなり萎えて
Torque採用状態からSQL直書きに方針を戻してしまった経験がある…。

252 ：デフォルトの名無しさん：03/06/23 01:09

.NetのDataAdapterはインターフェースみたいなもんで、
それ自身は何もしてくれない。
DELETE INSERT UPDATEなどの、SQLは自動生成もできるが、手書きが基本らしい。
それで、こいつを経由してDataBaseのメモリーコピーをDataSetというものに入れる。

DataSetに入れてしまえば、DataGridなどのGUI部品と連結ができる。
並び替えやページングのイベントが定義されてるので、
そこにちょこっと、コードを書いてやれば、並び替えやページングのできあがり。

VB厨の俺には小難しくてよく分からんです。
今はEmployeesなどのテーブルクラスと、Employeeレコードクラスを作って、
Employees#selectでEmployeeオブジェクトをhashmapやCollectionに入れてます。
どうやって、DataSetに移行しよう、、、

253 ：デフォルトの名無しさん：03/06/23 03:54

>>247
いやだから、ResultSetをラップするまで行かなくても
SQL文の発行を一部のクラスに追いやることぐらいできるでしょって
言ってるわけさ俺は
そういうクラスを自動で作ってくれるのがTorqueだと俺はおもってる
厳しく言えば、ただそんだけってこと
なので、いままでクラスの設計で半ラッピング状態で
やってきた俺にとって、わざわざTorqueその他のラッピングつーるなんて
使う意味ないねってことよ

＞クエリをクラスにカプセル化するような方法は一般的ではないのでしょうか？
これこそオブジェクト指向でないの？

254 ：そんな低レベルな話よりも：03/06/23 04:26

すごいねここ
http://strangeworld-honten.com/cgi-bin/bbs.cgi

255 ：デフォルトの名無しさん：03/06/23 08:37

SELECTを外に追い出す行為はあまり好きではない。
やはりソースが分かれると可読性が下がると思う。

256 ：デフォルトの名無しさん：03/06/23 12:42

俺はCastorやHibernateにTorqueのCriteriaっぽいクラスをかぶせて
使うようにしているので、「東京都に在住のユーザー一覧は以下の
ようにして取得してね」みたいな指示だけ出すようにしてる。
プロジェクトメンバーのメンテナンス能力は別に気にならないなあ。

Pref tokyo = PrefManager.fetchPref(13);
UserCriteria uc = new UserCriteria();
uc.setPref(tokyo);
ArrayList users = UserManager.fetchUsers(uc);

257 ：デフォルトの名無しさん：03/06/24 17:42

すれ違いだけど、漏れははSQLのラッパーより、
htmlの特にtableのラッパーが欲しい。
JSPで書いてもhtmlとjavaコードが
乱立するし、書いていて非常に不毛に感じる。

細かな設定のできる（例えばカラーで極細の罫線の代わり
をさせたりする）クラスライブラリないかな。

やっぱ、自力で専用ライブラリつくってるのかな。

258 ：デフォルトの名無しさん：03/06/24 23:30

>>257
普通にカスケードスタイルシートかけばいいだけでわ？

259 ：デフォルトの名無しさん：03/06/25 00:15

>>258
ｺﾞﾒｿちょっと、舌足らずだった、
tableを生成するのに
（行追加とかcolspan,rowspanや、極細罫線とか）
ラッパーメソッドで細かな設定
ができるクラスライブラリがないかなと。

260 ：デフォルトの名無しさん：03/06/25 00:37

>>259
明確にほしいものができてるみたいだったら、タグリブを自分でつくれば？

261 ：デフォルトの名無しさん：03/06/25 00:42

>>259
http://jakarta.apache.org/ecs/index.html
こーゆーのではなくて？

262 ：デフォルトの名無しさん：03/06/25 00:57

なので、みんな独自の汎用ライブラリを
自分で作っているのかなと聞いてみた。
やっぱ、260も作っているの？
（SQLまでもラップするのがあるのだから、
こういうのもあってもいいのかなと思ったわけ。）

Javaコード内で枠だけ作ってさらにコード内で
値をいれたりとかね。
作っても（つくれるかな？）いいけど
その時間があれば、ベタで書いた方が早いかな．．．

263 ：デフォルトの名無しさん：03/06/25 01:02

>>261
そうそう、こういうのです。
今、ちらっと見ただけですが、
試して遊んでみます。
ありがとうございます。

264 ：デフォルトの名無しさん：03/06/25 01:45

>>262
俺はそこまでのヤツは必要になったことがないから作ったことはない。

が、必要になればまずは探す。
なければ仕方がないのでつくる。

265 ：デフォルトの名無しさん：03/06/25 01:47

>>261
ECSって使いどころが微妙じゃない？

266 ：261：03/06/25 22:11

>>265
微妙というか殆ど無いと思う。俺は使いどころイマイチわからん。
ただ、モノ自体は面白いと思うし、将来的には使い道出てくるかもしれないし。

漏れは259が問題にしてるタグとスクリプトコードが混じったりするのは平気。
というかこれからはjellyっスよ（藁

267 ：デフォルトの名無しさん：03/06/26 02:18

jellyって実際どうよ？何かまだまだって気がするんだが
情報激しくキボンヌ

268 ：デフォルトの名無しさん：03/06/28 00:49

>>267
俺もまだまだだとおもう。
ただmiddlegenとかxdocletとか見るにつけ、そういう流れはあるんだろうなーとか。
将来的にORマッピングの強力なツールとなるかもしれない気がする悪寒。
んであとはmavenな。jelly採用してるし、mavenがブレークすれば
ついでにjellyもブレークするんではなかろうか？って勝手に思ってる。

情報はぜんぜんないね。英語の情報もあんま無いし。
1.0リリースするまではCVSでソースとかテストケースをウォッチするぐらいしか
なさそう。テストにあるjellyスクリプトが一番参考になるんじゃないかなぁ。
でもまだタグライブラリの方は動かないの結構多いけど（ｗ

269 ：デフォルトの名無しさん：03/06/30 12:36

>>268さんくすこ
jelly興味はあるんだが取っ付きがなー

270 ：デフォルトの名無しさん：03/07/12 08:25

今更でｽﾏｿが、O-R Mapping Frameworkの利点をRDB厨の私に分かりやすく
説明してもらえる情報源ってないでしょうか？
SQLを知らないJavaPGでも開発できる！
→RDB使うんだからSQLぐらい勉強しろよ！
物理設計が省力化できる！
→RDB使うんだから物理設計ぐらいちゃんとしろよ！
　というかE-R系ツールでも結構できるのに。
SQLだと保守性が悪い。
→そのためのドキュメントやん。複雑ならストアドも併用しる。

というわけで、Torqueの特集記事をJavaWorldやWebDBPressで読んだのでつが、
利点が全く理解できないのでつ。
でもJDOは勉強しようと思ってる...

271 ：デフォルトの名無しさん：03/07/12 09:00

>>270
SQL云々かんぬんでなしに、オブジェクト指向における永続化層を自作しなくてよいという話。
これだけでバグと単体テスト工数が3分の1ぐらい軽く減るだろ？

272 ：270じゃないよ：03/07/12 09:55

>>271　横レスすまん
つまり、きちんとしたオブジェクト指向による設計を行えば、オブジェクト-DB間の
コードは大体似たようなものになる（というかワンパターンになる）から、そこを
自動生成できるようにします、というのがMapping-Frameworkのコンセプト、という
ように捉えたんだけど、合ってるかな？

273 ：271じゃないよ：03/07/12 12:25

>>272
SQLとJavaはその設計思想からして違うものだからレイヤーとしてO-RMappingを使用して
DBとJavaの層を接続しようと。

EJBなんかもその一部だよね。

274 ：デフォルトの名無しさん：03/07/12 20:57

>>270
単純に、

Person p = new Person();
p.setName("お前");
db.save(p);
Person p2 = db.retrieve(Person.class, "お前");

こういうコーディングができると楽じゃない？

275 ：デフォルトの名無しさん：03/07/12 21:05

>>274
じっさいそういうことやってんだが
絶対にキャストが絡むよな
せめて見えない位置にキャスト隠して欲しい

276 ：デフォルトの名無しさん：03/07/13 05:51

>>275
無理でしょ。ユーザが勝手に定義したクラスの型で返すメソッドを、
どうやってライブラリ内部に作るのよ？

277 ：デフォルトの名無しさん：03/07/13 10:02

>>276
んー。JavaBeansという前提ならばBeanUtilのcopyPropertiesみたいに
リフレクション使えばなんとかなると思うし、実際そうしていると思うんだけど。

278 ：デフォルトの名無しさん：03/07/13 10:17

>>277
ユーザが指定したクラスの『インスタンス』は返せるけど、
ユーザが指定したクラスの『型』では返せないでしょ。
インスタンスは動的だけど型は静的なんだから。

>275 はそこにキャストが入るのがいやだといってるということだと思う。
でもラッパーかませばいいだけの話だと思うけど。
あるいはコード生成機能をするようなやつならそこまでやってくれる可能性がある。

279 ：デフォルトの名無しさん：03/07/13 12:40

>>274-278
素朴な疑問ですが、そういう風にobject風味になればなるほど、保守できる人材
が減ると思うのですが、皆さんの周囲はその議論レベルは理解できる人たち
ばかりということなんでしょうか。

280 ：279：03/07/13 12:46

つまり、>>274のｺｰﾄﾞにｷｬｽﾄが絡んだものがｴﾝﾃｨﾃｨ分だけあるとして、
本当にSQL直打ちより保守性が上がるのかなと思ったので
それ(保守性を上げる)にはかなり工夫が必要だと思い、
その工夫を理解できる人材がどれだけいるのか？と思ったので

281 ：デフォルトの名無しさん：03/07/13 13:16

使ったことないけど Relaxer みたいにテーブルから自動生成するのもあるよね？
ああいうのはどうなの？

282 ：デフォルトの名無しさん：03/07/13 18:09

>279-280
あちこちにSQLがちりばめられた状態で、
読み込むテーブルのWHERE条件の変更があったりした場合のことを考えてみそ。

下っ端にSQLなぞ書かせたくないというのもあるな。
複雑なSQLと複雑なコード、どっちがデバッグしやすいかとかも。

283 ：282：03/07/13 18:14

キャストに関しては、Employees(もしくはEmployeeCollection)クラスを
作っちまえば解決。

284 ：277：03/07/13 19:17

>>278
俺には型にこだわる理由がわからん。
たぶんコンパイル時にタイプセーフが保障されるのを期待してると思うのだけど、
O-Rマッピングに関わらずそれはJavaでは難しいと思う。いまのところ。
Java1.5のGenericに期待っつか。

285 ：271じゃないよ：03/07/13 20:55

>>279
逆だな。
Javaのコードの中にSQLといった別の言語が入り込むほうが保守の手間はかかる。

かからないと思っているのは今までの作り方がそれだけであったからそういう思いをしてしまうだけだと思う。

286 ：デフォルトの名無しさん：03/07/13 20:59

つーか、元々レイヤーが異なるものなのだから分離するのは自然だと思う。

287 ：274：03/07/14 04:00

俺は単純に「他人の書いたSQLは読みたくない」が「他人の書いた
Javaソースなら読んでもいい」と思ってるから、現状でもそんなに
不満は無いねえ。

>>275が書いていたキャストの問題はユーザー定義クラス毎に
ラッパークラスを生成するようにしているから、別に意識してない。

Person author = PersonManager.retrieve(personId);
Book book = new Book(title);
book.setAuthor(author);
BookManager.store(book);

288 ：_：03/07/14 04:02

http://homepage.mac.com/hiroyuki44/

289 ：デフォルトの名無しさん：03/07/14 08:45

>>287
スレ違いの指摘だが、そういうのはラッパーと呼ばずファクトリと呼ぶ。

290 ：274：03/07/14 15:54

>>289
そうか、そう言われてみればそうだな。
CastorJDOやHibernateの上に被せて使うんでラッパークラスということに
してしまっていたよ。

291 ：sage：03/07/14 17:26

CMPにしてもO/Rツールにしても、制作や保守効率は
上がるけれども、どうしても実行パフォーマンスが
自分でSQL書いてJDBCやる場合よりも劣ってしまうのが
難点。(勿論シンプルな問い合わせなら変わらないけど)

O/Rツールを導入して、取り扱いデータが結構増えてきた
段階でこのことに気づいた。まぁ、最初にちゃんと
検証しておかなかったのが悪いのだけど。
生成されるSQLが効率的なものかどうかは導入前に
ちゃんと確認しておくべきだね、当然なんだけど。

292 ：291：03/07/14 17:27

sage間違えた。

293 ：デフォルトの名無しさん：03/07/14 18:01

いくつかいじってきましたが、結局の所、WebObjectsが持つEOFが一番ラクだし
融通きくし、安定してると思ってる…

294 ：デフォルトの名無しさん：03/07/14 21:59

実際、ORマッパー書けばわかるけど
ORマッピングツールって別にSQLを簡単に書くためのツールじゃないんですよ。

将来、RDBMS以外に永続化しよーってときに効くツールなんですよ。
そんな実装は一生ありえなさそうですけどね。

295 ：デフォルトの名無しさん：03/07/14 22:17

>>294
XMLDBって最近名前は聞くようになってきたことない？

296 ：fusainasan：03/07/14 23:12

>>293 あ、漏れ、マカーなんだけど。
WebObjectで構築されたと統合2ch型掲示板システム「VanquishBBS」
http://web1.aaacafe.ne.jp/～tetsuyak/cgi-bin/WebObjects/VanquishBBS/index.html
EOFとか熟知している人が作るとこういうもんもができあがるらしい。
掲示板なのに負荷分散とかヘーキでしやがる。WebObjectってこういうのカンタンなの？

297 ：fusainasan：03/07/14 23:13

しまった、マカーなんでサファリだと～が全角になっちまうんだ(´Д｀;)鬱...

298 ：デフォルトの名無しさん：03/07/15 01:01

>>296
WOでなくてもそういう風に作ろうと思えば出来る程度のことだと思うが。
掲示板程度で開発生産性や負荷分散云々は多分比較するほどの差はつかん
と思うよ。別にAP鯖で負荷分散しなければならんということでもないし
【簡単】の定義も様々だと思うしな。ちなみに漏れは元WO使い。今は使わん。

299 ：山崎渉：03/07/15 09:40

　__∧＿∧_
　|（　　＾＾）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

300 ：デフォルトの名無しさん：03/07/15 16:48

WebObjectsってアプリケーションをクラスタリング構成にするのが
容易なのがウリじゃなかったっけ。

301 ：デフォルトの名無しさん：03/07/15 16:52

ウリナラマンセー

302 ：デフォルトの名無しさん：03/07/15 20:46

>>298
掲示板といえども、2chやYahooぐらいの規模になると、アクセスがグッと集中した時とか、
鯖が負荷に耐えられないってことあるじゃん。そんなとき、負荷分散構成になっていて、
３０台のサーバーで一つの掲示板データをやりとりできるとなると、
少なくともユーザはイイ思いできると思うんだがなぁ。

証券関連のシステムなんかだとそれがよく実感できるのだが、掲示板でも同様のような気がするんだけどな。
１台の高価・高速な鯖で動かして大量のトランザクションを裁いたとして、鯖が何らかの原因で落ちたときを
考えると負荷分散のメリットは大きいとおもうのだが。

303 ：デフォルトの名無しさん：03/07/15 21:16

>>302
もまいが言ってるのは負荷分散じゃなくて高可用性だな。
目的が違う。

負荷分散のためのオーバーヘッドって結構あるよ。
それはわかってるかな？

304 ：デフォルトの名無しさん：03/07/15 22:13

>>303
アクセス集中時も想定してるから負荷分散でもあってんじゃない。
一台が同時にさばけるリクエスト数とかも、ある程度決まってるわけだし。

でも分散環境で掲示板のデータ保存にDB使うと大変だろうなぁ。
最低限クラスタするにして、DBだけで相当な値段がいきそう…

305 ：298：03/07/16 00:15

>>302
WOだからどうこうって話じゃねぇだろ？ってことを言ってる。
証券関連が云々というが漏れも証券のネットトレーディングの開発
やってる。だから、はっきりいう。掲示板程度では何を使っても簡単の
度合いはそんなに変わらん。ハードの手配で決まる話だ。
その程度でWOを引き合いに出されてもWOが安っぽくみえるだけだ。
証券で使ってるのならそこをアピールするよし。掲示板では迫力不足。

306 ：デフォルトの名無しさん：03/07/16 08:59

>>296のＨＰみたけど、ハードウェアと７万ちょっとで負荷分散？JMSも使う？
しかも、たかが掲示板で？2chみたいな数百もある掲示板を１台のDBで
運営するつもりか？>>303のいうように、
負荷がおもいきりかかったときはつながりにくい・おちにくいサイトになっているとは
思うが重くなりそうな。掲示板ってレスポンス命じゃないかねぇ。１台のバカっ速い
鯖で運用させたほうが良いよな。
でも、この手のフレームワークを使った掲示板システムはフリーでは観たこと無いからポイントちょっと高いカモ。
（でもウェブオブジェクトってよくわかんない。７万だし、大したことなさそう）

307 ：デフォルトの名無しさん：03/07/16 13:19

WebObjectsの７万って、イメージ的に諸刃の剣だよな。
以前は700万だったから、イメージ的なありがたみ？があったけど、
いきなり７万になったら、「？」って思う。
70万だったら「ふむふむ、よさげだけど高いな」って感じか。
結局、モノは凄いのに認知されないんだよな。マイナーだし。

308 ：デフォルトの名無しさん：03/07/16 17:10

>>306はイタイいな。

309 ：デフォルトの名無しさん：03/07/16 18:51

>>307
>>結局、モノは凄いのに認知されないんだよな。マイナーだし。
モノのすごさを>>306のアプリケーションが証明してるとおもう。たぶん、そこのサクーシャは
WebObjectのすごさを知らしめたく、あえて掲示板というアプリを開発したのかなと妄想炸裂
させたりする。だって、ふつー、掲示板ごときでくらすたりんぐしねーもん（ｗ

310 ：デフォルトの名無しさん：03/07/16 19:21

すごさをアピールしようとして掲示板ｼｽﾃﾑを選び、
その必然性の無さがアピールされてしまってｼﾊﾟｰｲ（ｗ
いや、EOF最強なんだけどさ、ﾂﾌﾞｼが利かねんだよね。

311 ：fusianasam：03/07/16 19:32

>>310
必然性がないから、フリーでばらまいていると思う。これでビジネスやろう、なんて人は無いと思うが（ｗ
ｻｸｰｼｬもそこらへんわかってんじゃないの。別にクラスタリングが必須というワケでもなさそうだし。ただその機能もサポートしてるってだけでしょ。
EOFがﾂﾌﾞｼきかない、というのは、ADOだってJDOだってEOFと同じ道具のｳﾁの一つだから、ﾂﾌﾞｼきかない、といえばきないような。
掲示板だったらPHPとかPerlなんかで十分。2chぐらいの規模・アクセスだったら考えるけど。

312 ：デフォルトの名無しさん：03/07/16 19:41

でも、WOは、技術的メリット以前に、知名度も低いし、
EJB/Servlet&JSPコンテナとして使うとWOらしさが引き出せない。
んで、顧客へのアピール度も低いんだよな。
USはうまくやってるけど、日本じゃ無理だろ。

313 ：fusianasam：03/07/16 20:01

漏れの所は知名度なんか関係なしに、
いくつか製品を評価して最終的にWOにしたな（金融系をメインでやるSIerなんだが）。
他SIerとのコラボはめったにないし、、、まぁ、環境によりけりってところかなー。
確かに便利だよ。EOFってーのは。これぐらい独自性があるとパテントぐらいあってもいいんじゃないの？

314 ：デフォルトの名無しさん：03/07/16 20:51

EOFは、確かパテント取ってるはず。

315 ：デフォルトの名無しさん：03/07/16 21:45

またそんな出鱈目を。ﾏｶｰの妄想ですか。禿信者はこれだから困る。
いつもはじめじゃないといけないコンプレックスの固まりだな。ﾌﾟｯ.

マイナー製品がパテントとるわけないだろ。ましてやアップルだぜ。おまえら正気かよ（ｗ

316 ：デフォルトの名無しさん：03/07/16 22:07

何も知らないｱﾌｫが吠えてるな。
信者ﾏｶｰは、EOFなんて知らないんじゃねーの？ｗ

EOFがパテント取ってるのは相当昔じゃなかったっけ？
10年くらい前からある技術だし。元々はNeXTの技術。

317 ：デフォルトの名無しさん：03/07/16 22:37

段々ｽﾚ違いでｽﾏｿが、俺も>>312に同感だ。
WOが幾らいいソフトだろうが、幾らWOに詳しかろうが、それだけじゃ現状では
Web開発者としての市場価値は？？じゃない？
WO好きなら趣味でやるのもいいだろうが、趣味のWeb開発なんてそんなにやる
もんじゃなし。というわけで俺は普通にJ2EEに乗り換えたよ。

318 ：デフォルトの名無しさん：03/07/17 00:05

フレームワークの価値は、「適度に広まっていて、イザ新規開発あるいは
既存システムの保守をおこなおうというときに、技術者の教育コストを
無駄に抱えないで済む」ことに真骨頂があると思われ。
ある程度開発者が集まるならば、そいつら集めて作らせればいいだけ。

そういう意味で、マイナーフレームワークは存在価値が微妙だし、俺様
フレームワークは無価値。大体同じようなことをやってくれるなら、多少
欠陥があろうとデファクトを使うほうが、お客さんのためだろう。

技術者の興味のコストをお客に押し付けるのは犯罪的だと思う。

319 ：デフォルトの名無しさん：03/07/17 08:26

>>技術者の興味のコストをお客に押し付けるのは犯罪的だと思う。

激しくムカつくセリフだが間違ってない(;´д｀)

320 ：デフォルトの名無しさん：03/07/17 09:14

>>317
漏れ、運用屋やってるんだけど、WOを動かす鯖を預かる事例が、今年に入って
急に増えてきたよ。ﾏｼﾞ妄想じゃなくて。需要っつうか、使ってるところは
増えてきているんじゃないの。中には1/2埋めるところもあったし。

321 ：デフォルトの名無しさん：03/07/17 12:53

なんかスレ違いになってきたﾖｶﾝ

322 ：デフォルトの名無しさん：03/07/17 13:01

とりあえず、WebObjectsに特化した話題はスレ違いだ。
以後、こっちでﾔﾚや

WebObjects nsDictionary.valueForKey("５スレ");
http://pc2.2ch.net/test/read.cgi/php/1044328908/

323 ：デフォルトの名無しさん：03/07/17 13:12

そのAppleが10.3にはJBossを入れるらしいね。
プリインストールなのかCD-Romに入ってるだけなのかは
知らないけど。

JBoss4では独自のJDO実装もできてるね。EJBとどっち
使えばいいんだろう？

324 ：デフォルトの名無しさん：03/07/17 14:20

お。なんだ、専用スレがあったのか、ｻﾝｸｽｺ

325 ：デフォルトの名無しさん：03/07/22 22:42

bc4jに関するコミュニティーて一つもみつからないんだけど
どこかにありますか？

326 ：デフォルトの名無しさん：03/07/23 19:28

>>325
君が作れば誰かは集うよ。

327 ：デフォルトの名無しさん：03/07/24 13:10

bc4jって何？

328 ：デフォルトの名無しさん：03/07/24 15:05

>>327
Borland C++ Compiler Ver 4.0J
Jは日本語版の意味だろうね。

329 ：デフォルトの名無しさん：03/07/24 17:41

↑
面白すぎて腹痛いからWhiteSpaceでも一人でやってろ

330 ：デフォルトの名無しさん：03/07/25 13:13

JDO実装ってjdocentralに載ってるのと↓にのってるプロダクトでほぼ全部ですかね？
http://pnuts.org/wiki/index.pnut?language=ja&name=JavaDataObject

331 ：デフォルトの名無しさん：03/07/25 13:25

今更でなんですがJavaPressの最新号でJDO特集やってますね。
http://www.gihyo.co.jp/magazines/javapress

立ち読みでざっとしか見てませんが、
日本語でここまでまとまった資料or特集記事って初めてのような気が。

332 ：デフォルトの名無しさん：03/07/26 02:54

mappingする事で、javaソースにsql文が埋め込まれていない
状態にはなりますが、
いくらmapping-frameworkがすばらしく設計されていたとしても、
アプリケーション全体をオブジェクト指向の視点でみると
不自然な設計になりませんか？

たとえばアプリケーションの固定値（環境変数等）をＤＢで持っている場合、
自分は固定値を管理するクラスをつくろうと思いますが、
何らかの形でＤＢアクセスするためのクラスを渡す機構が必要になるでしょうし、

単純にユーザＩＤが１番のレコードの名前を変えたいという処理がリクエストを
またいでいた場合、ＤＢアクセスを減らすためにユーザをマッピングしたクラスを
保持していなければいけなくなります。その際に自動生成されたクラスはいじりたく
ないのでラッパークラスの作成を考えてしまうのですが、
そうすると更新の時はやっぱりマッピングクラスを何らかの形で渡さなければ
いけないのであんまし意味がなくなります。

どちらにしろＳＱＬ文を埋め込んでしまうとオブジェクト指向としてはきれいな設計
になるのではないかと思います。

私は、ソースにＳＱＬ文を埋め込むのはかっこわるいと思っています。
しかし、フレームワークを使うと設計が前時代的になるのではないかと思っています。
そこがトレードオフなのかもしれませんが、

要するによい設計法やパターンがあればそれを教えて欲しいと思っています。
よろしくお願いします。

333 ：デフォルトの名無しさん：03/07/26 04:26

おい、思ったんだけど
今俺XML関連いじってんだが
XPathとかあるじゃん？
あれも、SQLと同じだよな
あれもマッピングするって言うの出てきてるの？

334 ：デフォルトの名無しさん：03/07/26 09:48

>>333
XPath じゃなくて XQuery でない？

335 ：デフォルトの名無しさん：03/07/26 10:14

いやいや、俺の言ってるのは
XPathです　/element/child[@id=01]ってやつね
まあ、XQueryでも俺の言いたいことはおなじなんですけどね

まあ普通にやれば
XPath.newInstance(
"/"
+ ROOT
+ "/"
+ NAME
+ "[@"
+ ID
+ "="
+ bean.getId()
+ "]");
という具合になっちゃうわけです

336 ：デフォルトの名無しさん：03/07/26 10:34

>>332
別にオブジェクト指向を追及すのがフレームワークの役割じゃないだろう。
素人が混ざっている多人数での生産性を安定的に向上させることが
目的だわな。その意味ではオブジェクト指向としての自然さを崩すことも
ありだろう。

337 ：デフォルトの名無しさん：03/07/26 10:57

>>333
relaxer

338 ：デフォルトの名無しさん：03/07/26 11:05

>>336
同意。あんまりオブジェクト指向にこだわりすぎていると
ろくなことないよね。
特にRDBとオブジェクト指向のミスマッチはいかんともしがたいので
適当なところで割り切るのが吉かと。

339 ：デフォルトの名無しさん：03/07/27 00:03

>>338
それ大事！

340 ：デフォルトの名無しさん：03/07/27 02:36

末端の人が、Javaさえわかっていれば大丈夫にしたいという事だろ？
わざわざDB毎に違うSQLをチームみんなが覚えなくてもいいと。

341 ：デフォルトの名無しさん：03/07/27 23:33

>>332
クラスとインスタンスの区別が付いてないみたいだがそれは置いといて…

>たとえばアプリケーションの固定値（環境変数等）をＤＢで持っている場合、
>自分は固定値を管理するクラスをつくろうと思いますが、
>何らかの形でＤＢアクセスするためのクラスを渡す機構が必要になるでしょうし、

たいていのフレームワークでは、DBアクセス用クラスのインスタンスを
アプリケーション側で受け渡すような必要は無い。
もっとマシな設計になってるよ。

>単純にユーザＩＤが１番のレコードの名前を変えたいという処理がリクエストを
>またいでいた場合、ＤＢアクセスを減らすためにユーザをマッピングしたクラスを
>保持していなければいけなくなります。その際に自動生成されたクラスはいじりたく
>ないのでラッパークラスの作成を考えてしまうのですが、

リクエストを跨いだトランザクションをサポートしたフレームワークなら、
自動生成されたクラスをいじる必要は無い（そのまま保持してればいい）。
それと、今時はデータオブジェクトクラスの自動生成は行わないフレームワークの
ほうが主流のような気が。

342 ：デフォルトの名無しさん：03/07/27 23:46

>>338
禿同。

343 ：デフォルトの名無しさん：03/07/27 23:48

そういえばよく日付とか扱うよな。
あれってCURRENT TIMESTAMPとか使っちゃったりしてさ。
DB中心で扱うことが多いんだけど（たまたまね。）
日付はJAVA(アプリサーバ)とＤＢサーバどっちで扱ったほうがいいと思う？

344 ：デフォルトの名無しさん：03/07/27 23:51

>>343
どっちでもいいのでは？

345 ：デフォルトの名無しさん：03/07/27 23:54

APとDBでサーバが違うからDBに統一はしてる。
NTP使うのもめんどくさいからな。
そうだな。どっちでもいいや。

346 ：デフォルトの名無しさん：03/07/28 00:44

最近多いなRDBマッピング特集。
CMP、BMPは話にならないことに気づいたか？

347 ：デフォルトの名無しさん：03/07/28 00:53

>>346
EntityBeanは分散でつかえる技術だとあれほど言ってるのにまだわからんのか
話を混ぜないでください

348 ：デフォルトの名無しさん：03/07/28 08:03

>>347
EntityBeanは、リモートやトランザクション制御できたとしても
うれしくないやろ。
つかえない技術ちゅーことが、一般的な認識になったってことでしょ。

349 ：デフォルトの名無しさん：03/07/28 12:19

>>348
ばかやろうばっかだな

「EJBはRDBマッピングの技術じゃない」って何回言えばわかるんだよ馬鹿
EJBはこのスレにはカンケーないんだよバカ

350 ：デフォルトの名無しさん：03/07/28 12:43

>>349
だからEJBを使ってそういうことをやろうとすると云々ってことだろ。

信者ｳｾﾞｪよ

351 ：デフォルトの名無しさん：03/07/28 22:20

SessionBeanとORマッピングの組み合わせはアリだと思うんだが…
分散にも対応できるし。

EntityBeanは面倒くさいよ、なんか。

352 ：デフォルトの名無しさん：03/07/28 23:15

最近いろんなところで言われてるが
SessionBean+JDO
っつ組み合わせに流れつつあるみたいだなや。

EntitiyBeanは問題外だと思うけど、JDOもそんなにいいかなぁ…。
なんかどのORツールもしっくりこない。

353 ：デフォルトの名無しさん：03/07/29 00:19

ORマッピングツールは100%全部それでまかなえることを
期待しちゃだめなんだろうな、きっと。
60%くらいの自動生成でラクチンして、後は手書きでSQL、
くらいの心構えでやるのがよさげ。
とかいいつつ、俺は一度もマッピングツール使ったことないけどね・・・

354 ：デフォルトの名無しさん：03/07/29 00:26

ああ、RDBを捨てられたらいいのにねえ…

355 ：デフォルトの名無しさん：03/07/29 07:14

スキーマの変更に強くないと、マッピングって言えないよな

今までのマッピングツールってただ単にSQL文を隠してるだけだと思わない？

そんなことさ、実際普通のプログラマはやってたわけよ

自動生成っていうのはいいけどオブジェクト指向を適用するのはソコじゃないんだよな

それからさ、データベース特有の機能使えないんだったら

プログラマーからどのDB使ってるのか完全にわからなくして欲しい

っていうか、DB側もオブジェクト指向に歩み寄ってきて欲しい←非常に重要
っていうか、DB側もオブジェクト指向に歩み寄ってきて欲しい←非常に重要
っていうか、DB側もオブジェクト指向に歩み寄ってきて欲しい←非常に重要

356 ：デフォルトの名無しさん：03/07/29 09:46

今時、どんなに小さいシステムでもOracle以外は認めないとか酔狂な事を言っている
企業がゴマンとあるからな。信頼性の問題云々だと。
そういう会社に限って、保守に金掛けてなかったりするんだけど。

というのは置いておいて、Oracleがオブジェクト型になれば、きっとみんなそうなるんだろ？

357 ：デフォルトの名無しさん：03/07/29 13:02

ObjectStoreでも使っとけ。

358 ：デフォルトの名無しさん：03/07/29 14:33

なに？
ObjectStoreってObjectの丸投げモロ出しできるの？
いいねぇ
でも、そうなると言語間でやり取り大変そうだ

やっぱ究極はXMLが高速になれば・・・・

359 ：デフォルトの名無しさん：03/07/29 22:24

今Torque試してるけど、Viewと組み合わせれば
パフォーマンス的にも問題なく使えるね。

まあ、時代はJDOへと移るんだろうけど…

360 ：デフォルトの名無しさん：03/07/31 16:04

Torqueについて質問させてください。

ORDER BYを使ったデータの取得を行おうと思い、以下のコードを試したのですが

Torque.init("Torque.properties");
Criteria c = new Criteria();
c.addAscendingOrderByColumn(MytablePeer.Field1);
List list = MytablePeer.doSelect(c);

doSelect()の時点でNullPointerExceptionが発生してしまいました。
addAscendingOrderByColumnを使わずに実行した場合は問題なく動きますので
Torque.propertiesの設定には間違いはないと思います。
addOrderByColumn()を使った場合でも同様の現象が出ました。

DBはMSSQL2000 Torqueは3.1 OSはWindows2000です。
どなたか同様の現象がでた方いませんか？

http://www.mail-archive.com/[email protected]/msg12713.html
おそらく同じ現象かと

361 ：デフォルトの名無しさん：03/07/31 16:21

>>360
あなた、3月ぐらいにJakartaの掲示板に同じ質問しました？
今ググッて見たらあなたと同じような現象らしいです
その方も､同じメーリングリスト指していました
やっぱ、バグなんですかね？
何か特別な、スキーマでしょうか？
差し支えなければスキーマ定義教えてください

362 ：361：03/07/31 16:23

追加で質問なんですが
ソート対象のカラムは[NOT NULL]定義になっていますでしょうか？

363 ：360：03/07/31 16:31

>>361
<table name="Mytable" idMethod="none">
<column name="MemberNo" size="4" type="VARCHAR" />
<column name="GroupCd" size="3" type="VARCHAR" />
<column name="Name" size="24" type="VARCHAR" />
<column name="Y-Cd" size="2" type="VARCHAR" />
<column name="F-Flg" type="BIT" />
<column name="HolD" type="REAL" />
<column name="Mail" size="50" type="VARCHAR" />
</table>

特別なことをしているとは思えないのですが。

jakartaの方は私ではないです。
今月のJavaWorldを読んで、使ってみようかと思って。

364 ：361：03/07/31 16:38

わかりました

私の方も>>363のスキーマ定義で
Win2000＋MySQL＋J2SDK1.4.1.02
で試してみます（MS　SQLは持っていないので参考になるかどうかわかりませんが・・・）
Torque最近使ってないので思い出しながらやってみます

365 ：360：03/07/31 17:56

>>364
MySQLで実行した場合は成功しました。

また上記のスキーマ定義で、MemberNoにrequired="true"を追加して
実行しましたが、やはり失敗でした。（エラー個所もいっしょ）

やはりバグですかね・・・

366 ：361：03/07/31 18:03

>>365

やってみました
んん？
なんでかな？MySQLでエラーでたｗ
addAscendingOrderByColumnのとき出るね

で、おれもEclipseなんだがaddOrderByColumnのときは
「Criteriaにこのメソッド使うべきではない」と警告でます

367 ：デフォルトの名無しさん：03/07/31 18:49

Oracleでも出るねぇ。
Win2000+Oracle8.1.7+J2SDK1.4.2
Torqueは3.0.2だけど。

368 ：360：03/07/31 19:36

>>366
そういえばbuild-torqueのjdbcも失敗します。
失敗というかテーブルの情報が取得できないみたいです。
（空のschema.xmlが作られる）

上記のスキーマもDBから作ったんじゃなくて、エディタで作ったやつですし。
この辺が原因かもしれないです・・・

MySQLだと問題ないですよ？4.0.2、Windows2000ですけど。

369 ：デフォルトの名無しさん：03/07/31 19:41

>>368
そういえばって…

370 ：361：03/07/31 20:21

てか、torqueってcreate-dbとかもDBによってエラーになるし・・・
いったいお前らは何をもってマッピングと言っているのか？
Jakartaの中でも最悪のメンバーでやってるんだろうな
そうか、タービンから独立したわけじゃないんだ
タービンからはじき出されたのですね

371 ：デフォルトの名無しさん：03/07/31 20:27

>>370
とっくにJakartaからもはじきだされてますよ。
Apache DB Project

372 ：デフォルトの名無しさん：03/07/31 20:29

>>371
それは昇格なのか？

373 ：デフォルトの名無しさん：03/07/31 21:19

業務アプリをやっている香具師に聞きたいんだが、
JDOを使うと開発効率や保守性は上がるんだろうか？

．．．結果として一覧表的なものを求められる場合が多いので、
かえってJDOを使うと大変かと。

374 ：デフォルトの名無しさん：03/07/31 21:28

>>373
まだ、はっきり言って過渡期なのにJDO使うやついないだろ？
「今回は見送りましょう」ってなる

375 ：デフォルトの名無しさん：03/08/01 00:26

「一番インパクトのある仕様」
なぜ英語(カタカナ)にするのだ？

376 ：デフォルトの名無しさん：03/08/01 01:49

>>360
>>361
以前、DBAdapterの設定が間違えた時にそういう現象(ORDER　BYでおかしくなる)が起きました。

生成したBase<TABLE名>PeerクラスのDATABASE_NAMEにセットされているデータベース名で
Torque.propertiesで設定するtorque.database.<データベース名>.adapterの値を設定してなかったため、
BasePeerクラスのcreateQueryやcreatePreparedStatementメソッド内の
「dbMap.getTable(table)」のコードの部分でDatabaseMapオブジェクトが取得できなくて例外(NullPointerException)がスローされていました。

「ORDER　BY」以外で動くのは単に「dbMap.getTable(table)」のようなコードが他の句の生成部分で使用されていないから大丈夫なだけだったようです。

・・・こんな簡単な問題ではない？

377 ：デフォルトの名無しさん：03/08/01 05:56

私の場合はTorqueでLimitがエラーがでてできなかったです。
んで、仕方なかったのでHibernateに乗り換えました。
日本ではTorqueが雑誌などで特集やってて人気あるけど
アメリカではHibernateの方が人気ありますよね。

378 ：デフォルトの名無しさん：03/08/01 06:04

http://esenden.com/rank/ninki/ranklink.cgi?id=groovy

379 ：デフォルトの名無しさん：03/08/01 07:28

hibernateの方が相当いいよ

380 ：デフォルトの名無しさん：03/08/01 07:37

>>379
そうか、今日ちょっといじってみるから
わからんことあったら教えてね　マジで

381 ：380：03/08/01 10:04

すいません早速、Hibernateの質問なんですが
プロパティーファイルとスキーマ定義XML、スキーマのBeanクラスをとりあえず作りました
この先どうすればいいのでしょう？

インストールフォルダのbuild.xmlをANTで起動したらHibernateのフォルダできちゃった。
これってHibernateのためのbuild.xmlファイルみたいですね・・・
Torqueと同じような感じだと思ってやってしまいました

このHibernateってクラス自動生成とかっていうのはないのですかね？
とりあえず、ためしにこのままコード書いてみたのですが
Sessionはどこで取得するのでしょうか？
Sessionが無いとsave()出来ないみたいなので・・

382 ：380：03/08/01 10:18

えーと
Sessionの取得方法わかりました

＞SessionFactory sessions = cfg.buildSessionFactory();
＞Session session=sessions.openSession();
これですね↑

で、いいとこまで行ったのですが
org/dom4j/io/SAXReader
これが含まれたJarファイルはどこで手に入りますか？
なんかコレが無いってエラーでます

383 ：380：03/08/01 10:23

dom4jだからlog4jと出所がいっしょなのかな？と思って
Jakarta行って見たのですが
やっぱないですね・・・

っていうかパッケージ名なんて一意のものだから
Javaのパーケージ検索用のディレクトリサービスあってもいいと思うんだけど・・・

384 ：380：03/08/01 10:25

あ、ありました
単純に
http://dom4j.org/
で、発見したよん

385 ：デフォルトの名無しさん：03/08/01 10:42

>>380
Hibernateの配布ファイルの中に入ってない？
lib/dom4j.jarってファイルがあるはずだけど。

Torqueは雑誌のサンプル読んで「これ便利か？」って疑問だったけど、
そんなにいいものなのならこれを機に試してみようかな。

386 ：380：03/08/01 10:49

いや、もう少しなんですが･･･

「hibernate_unique_key」っていうテーブルが無いって言うエラーでます

やっぱ自動生成しないといけないんじゃないでしょうか？
おしえてください

387 ：380：03/08/01 10:52

>>385
ありがとうございます
すんごい、バカでした僕
あれから、自分で気づいたんですが・・・
13MBのdom4jダウンロードしてしまった
なにしてんだか・・・

>>386にも書いたのですが
SQL自動生成ツールは無いのですかね？
「hibernate_unique_key」ってテーブル自分で作ってもいいんですが
どうせ、スキーマ定義わからないのでどうすりゃいいのか・・・

388 ：380：03/08/01 10:56

一応、コレの%HOME%\demo.batは正常に動くのでデータベース設定等は正しいみたいです

389 ：380：03/08/01 10:59

ああ、setupコマンド打てばいいのか・・・

390 ：380：03/08/01 11:01

う～
エラーは出なくなってプログラムは正常終了したが
データベースに書き込めてない・・・なんでだろう

391 ：380：03/08/01 11:04

session.save(obj);
session.flush();
コレだけじゃダメなんですか？

392 ：380：03/08/01 11:08

げー、なんか
「hibernate_unique_key」ってテーブルだけどんどん書き込まれて
肝心のオブジェクトの方のテーブルは書き込まれていない・・・なんじゃコレ

393 ：デフォルトの名無しさん：03/08/01 11:21

なんか380の独りチャット状態になってるな。
このままだとつまらないので情報提供。
Hibernate2のドキュメントの翻訳をしているところをﾊｹｰﾝ。
ttp://www.ozacc.com/library/
まだ4章までだそうな。ありがたく読ませていただきます。

394 ：380：03/08/01 11:25

>>393
ありがとうございます
いちおう、そこは参照してもらってます
いいトコまでいってるんですがね・・・

395 ：380：03/08/01 11:36

コードの書き方は、IDEの保管機能とかいままでのTorqueとかの経験で勘で出来るんですが

肝心の作業手順っていうか作業の流れがわかりません
↑これさえはっきりわかれば何の問題も無いのですが・・・

396 ：デフォルトの名無しさん：03/08/01 12:07

>380
transactionをcommitしろよ

Session session = sessaionFactory.openSession();
Transaction tx = session.beginTransaction();
SomeObject object = new SomeObject();
session.save(object);
tx.commit();
session.close();

397 ：396：03/08/01 12:09

Transactionオブジェクトをつくりたくないなら、

session.flush();
session.connection().commit();
session.close();

でも、いいぞ。

398 ：デフォルトの名無しさん：03/08/01 12:11

>387
SchemaExportツールは試したか？

java -cp hibernate_classpaths net.sf.hibernate.tool.hbm2ddl.SchemaExport options mapping_files

399 ：380：03/08/01 12:32

>>396
ありがとうございます
でも、ダメでしたエラー内容も変わらず・・
エラー内容：：net.sf.hibernate.HibernateException: SQL update or deletion failed (row not found)
これからデータ入れるのに「(row not found)」なんてあたりまえじゃん何だコレは・・・

>>398
ありがとうございます
SchemaExportは自分で気づいてつかってみました
で、setupコマンドは上手くいくんですが
それ以外のコマンドの使い方がわからず・・・

400 ：デフォルトの名無しさん：03/08/01 12:46

>>380 がんばって。参考になります。

401 ：デフォルトの名無しさん：03/08/01 13:06

>>380
なんでそんなに手こずるのさ。

SessonFactory sessions = new Configuration()
.addClass(Item.class)
.buildSessionFactory();

Item item = new Item();
item.setName("Item name");

Session session = sessions.openSession();
Transaction tx = null;
try {
tx = session.beginTransaction();
session.save(item);
tx.commit();
} catch (HibernateException e) {
if (tx != null) {
tx.rollback();
}
throw e;
} finally {
session.close();
}

402 ：380：03/08/01 13:22

>>401
すいません
いや、ですから
コードの書き方はわかるんですが

開発の手順がわからないのです

スキーマのXML、スキーマのクラス作る
SchemaExportツール叩く→なんかしらんがDB上にテーブル出来上がってる
メインのプログラム作る
動かす
エラー：：net.sf.hibernate.HibernateException: SQL update or deletion failed (row not found)
コミットのところでエラーになります
なので、もう一度一からやりたいのですが・・・
そもそも手順がこれでいいのかどうか疑問でして・・・

403 ：デフォルトの名無しさん：03/08/01 15:53

>>380
ttp://hibernate.bluemars.net/hib_docs/reference/html/or-mapping.html#or-mapping-s1-4
generatorの指定をidentityもしくはsequenceにするとすんなりいく予感。

404 ：401：03/08/01 16:27

>>402
それはスマンかった。
俺は手っ取り早く、手動でテーブル作っちゃってるからSchemaExportなぞ
使ったことも無かった。

今試してみたが、以下の手順で問題無くデータを格納できたぞ(PostgreSQL)。
*.hbm.xml作る
*.java作る
$ java net.sf.hibernate.tool.hbm2ddl.SchemaExport classes/*.hbm.xml
$ java net.2ch.Test

以下のようなシンプルなテーブルでもエラー出ちゃう？
ひょっとしてマッピング内容に起因する問題だったりして。
CREATE TABLE Person (
person_id SERIAL PRIMARY KEY,
name TEXT NOT NULL
);

405 ：デフォルトの名無しさん：03/08/01 23:57

DBのカラム名を日本語にしちゃった人は
ここらへんにでてくるMapping-Frameworkは
使えないと思っていいんでしょうか？

406 ：デフォルトの名無しさん：03/08/02 00:15

middlegenとかも使ってみてくんねーかな。

407 ：デフォルトの名無しさん：03/08/02 00:31

>405
一個ずつ丁寧にマッピングを書いてやれば使えないこともない。

408 ：山崎渉：03/08/02 02:03

（＾＾）

409 ：デフォルトの名無しさん：03/08/02 10:56

>>405
なぜに日本語のからむ？

410 ：405：03/08/02 13:00

お客様（DBの管理をする人）が
英語だとわかりにくいとおっしゃるので…
まあ二つ返事でOKしてしまった俺も俺だが・・・

411 ：デフォルトの名無しさん：03/08/02 14:20

普通そういう時はローマ字にするもんだが。

412 ：デフォルトの名無しさん：03/08/02 14:32

>405
英語のビュー作ってしのいどけ。

しかし、DBの管理人で分かりずらいから日本語にしてって、
すんげー低レベルな連中と仕事してるな。
そんなんで食っていけてうらやますい。

413 ：405：03/08/02 15:07

低レベルの話題ですいません。
DBっていってもアクセスだし…
管理人っていっても本職は事務だし・・・

414 ：デフォルトの名無しさん：03/08/02 16:47

ACCESSかよ…
MySQLかなんかで作り直してあげた方がいいんじゃないか？

415 ：401：03/08/02 17:40

>>414
MySQLで動いているシステムのデータをAccess(ODBC)経由で
閲覧してる、ってコトじゃないの？

416 ：_：03/08/02 17:41

http://homepage.mac.com/hiroyuki44/

417 ：デフォルトの名無しさん：03/08/02 19:07

>>360

もし、見ていたら確認してください

Web+DB PRESS（技術評論社）って言う雑誌のvol.15に
それの原因らしきものが書いてあります
P164参照してください
本屋行けばまだあるかも、もしくは技評のHPから
バックナンバー注文して

418 ：デフォルトの名無しさん：03/08/02 22:46

>>415
信じられんかもしれんがちょっとしたデータの管理にRDBMS使うと
いきなり高くなって予算取れないからってAccessそのもので管理する
ケースがあるんだよ。

まあ、部署内で閉じてて誰かがファイル開いてたりってのがすぐわかる環境だったら
正しい選択だとは思うんだが。

419 ：デフォルトの名無しさん：03/08/03 07:05

おい、取引先の担当さんよ！
PostgreSQLはそんなにダメですか？
MySQLはそんなにダメですか？
あんたの推してるOracleってそんなにいいんですか？
あなたの案件見ている限りじゃお金の無駄遣いですよ
そもそも、Oracle使えるんですか？
Oracle言ってみたいだけじゃないですか？

420 ：デフォルトの名無しさん：03/08/03 07:11

スレ違いだが。Oracle に払う金は安心料だからね。
安い、普通、ちょっと高め、高いの 4 つから選ぶとき、
値段しか判断基準がないとすればちょっと高いを選ぶのが人間心理。

421 ：デフォルトの名無しさん：03/08/03 10:35

>>420
なるほど。並・上・特上があったら上が一番売れる罠。＞うなぎ・すし

422 ：デフォルトの名無しさん：03/08/03 11:01

MySQLも保守契約ってあるだろ？

PostgreSQLもＳＱＡがあるんじゃない？

となると、知ってる名前じゃなきゃだめってことかなぁ？

423 ：　：03/08/03 11:03

>>419 ブランドの力をなめてはいけない。　ブランドはブランドを維持するために
莫大な投資と宣伝してるわけで…。

424 ：デフォルトの名無しさん：03/08/03 11:13

>>422
ＳＱＡじゃねえや、ＳＲＡのまちがいね。すんません。

425 ：デフォルトの名無しさん：03/08/03 11:13

>>423
やっぱ、あの暴力的なOracleの値段にくらくらきてしまうんですねぇ。

426 ：_：03/08/03 11:17

http://homepage.mac.com/hiroyuki44/hankaku07.html

427 ：デフォルトの名無しさん：03/08/03 22:20

>スレ違いだが。Oracle に払う金は安心料だからね。
金出せば安心なのか？
責任の所在料とかいうが、被害が出たときはOracleが出してくれる（た）のか？
不明な障害の時親身になって解決のサポートをしてくれる（た）のか？
サポート料とかいってパッチ料金だけなのじゃないのか？

まぁ、大体、みんな自分の財布から金がでていかないから
金を使いたがるんだよな。

予算の内、余った額はみんなに還元するプロジェクトでも
Oracle使うか？

428 ：デフォルトの名無しさん：03/08/03 22:31

まぁ、ここのスレはDBの機能はあまり使わず、
DBはストレージとして、ビジネスロジックは全部
アプリ側に埋め込むという開発が目的だから、
そういう使い方するだけだったらOracleはいらないな。

DBオブジェクトもテーブルと、インデックスぐらい
しか使ってないんだよね。さらに参照整合も使ってなかったり。

とスレのちょっとスレの内容の方向に戻してみる。

429 ：デフォルトの名無しさん：03/08/03 23:05

DBをストレージとしてしか使わないのって間違ってると思うな。
レイヤーの切り分けって重要だし、ストアドでやった方が簡単で速けりゃそっちを使う。
開発者の切り分けもしやすいし、DBでやるべき事をアプリでする必要ないじゃん。
こういう用途のフレームワークってないんだよね。だから自作するしかない。

430 ：デフォルトの名無しさん：03/08/03 23:55

>>429
ここのスレで、こういう意見を出す人もいるんだ。
オレもそうだよ、同意見だよ（ちょっと皮肉を込めていっただけ。）

DBはデータだけではなく、ビジネスロジックも一元化させ共有化
させる機能をもっている。

だから、トリガー、ビュー、ストアド、チェック制約、参照整合、
ユーザメッセージ（例外）等、DBの持つオブジェクト、機能を駆使して、
まず開発では、ビジネスロジック
　・これを更新したら、あそこのデータを更新する、
　・ここは指定値以下の数値しか入らないようにする、
　・DBエラーもそれに関して全て作り、どのエラーかもメッセージとして（APに）返す
等をDBで定義し、APはできるだけ、
（擬似的にでも）1テーブル（ファイル）のI/Oの感覚で開発ができる作りが美しいと思う。

AP側の開発者も本来の業務（UIや、APレベルでのプログラムの最適化、高速化）
に集中できる。

他のDBMSの移行時に大変だ、という意見が出るが、それは大変でアタリマエ。
オレらはアプリケーションシステムを作っているのではなく
データベースシステムを作っているのだから。
開発されたDBを変えることの意義を分かっていなく、
DBMSの変更を簡単に考えるのはちょっと賛同しかねる。

431 ：デフォルトの名無しさん：03/08/04 00:00

>ストアドでやった方が簡単で速けりゃそっちを使う。
>開発者の切り分けもしやすいし、DBでやるべき事をアプリでする必要ないじゃん。
俺はまさしくその考えなので、業務ロジックは結構ストアド(PL/SQL)で
組んでいる。社内の基幹業務のDB製品を変えるなんてことは想定もしてない
せいもあるけどね。
最近のOO設計を前提、イコールDBはタダの箱、というJava雑誌等の論調には
正直戸惑っているなりよ…

432 ：デフォルトの名無しさん：03/08/04 00:03

なるほどねー。
ひとつの社内システムや基幹システムに長期間携わるのならそれもありかも。
でも普通にSIやってるといろいろなDBMSを短期間で扱わなきゃならないから
どんなDBでも同じように扱える方法をどうしても選んでしまうのも事実。
そこまでひとつのDBMSの機能を使い切るまでに至っていないのも現状。

433 ：デフォルトの名無しさん：03/08/04 00:11

DBサーバへのアクセスがボトルネックになるようなシステムで、
ビジネスロジックサーバ側でできることはなるべくしておくっ
てのは、アリじゃないのかね。規模が大きいシステム限定の話
ですが。

DBMSの差し替えが絶対に発生しないようなら、全部DB任せは
楽でいいけど。

434 ：デフォルトの名無しさん：03/08/04 00:17

たくさんのクライアント　Web鯖等　ビジネスロジック鯖
以下省略　　　　　　　　Web鯖等　ビジネスロジック鯖　DB鯖
　　　　　　　　　　　　Web鯖等　ビジネスロジック鯖
　　　　　　　　　　　　Web鯖等　ビジネスロジック鯖
　　　　　　　　　　　　Web鯖等
　　　　　　　　　　　　Web鯖等
　　　　　　　　　　　　Web鯖等

こんなシステム、ありがちでしょ？

435 ：433=434=DB素人 JavaPG：03/08/04 00:57

DB鯖で、データの物理的なストレージへのアクセス周辺の機能と、
それ以外の機能を分散配置できるような賢い鯖ってあるのですか？

436 ：デフォルトの名無しさん：03/08/04 02:01

>>435
ビジネスロジックにデータ処理を持ってきたら持ってきたで
ネットワークへの負荷が上がるのが問題になると思うんだけど・・・

あと、DBMSの差し替えを気にしてるようだけど、DBMSの差し替えよりは
Viewやストアドを別PGで使いまわす方が発生頻度が高くない？
そういう事を考えるとDBMSの機能はフルに利用すべきだと思うよ。
※ORMを手軽に利用する気なら、Viewでゴリゴリは必須のような…

そもそも、規模が大きいシステムでDB鯖が貧弱な構成ってあんのかな？
ここ最近だったら、どこの大手もストレージ周りで稼ごうとするでしょ。

まあ、中小規模の開発だと結構ヤバイ構成を見かけるけどね。

437 ：436：03/08/04 02:09

あ、>>430-431で大体書かれてたのね。

いや、もうバリバリDBMSの機能は使いまくるべきだと思うよ。
Torque良く使うけど、更新系をORMに任せて参照系はViewで外部
切り出しのパターンで済ませてる。
それだと、チューニング時にDB管理者へそこら辺のメンテ振れるし・・・

正直結合する条件が一部変わったくらいで、Javaコンパイル→APPサーバー
再起動の流れはやってられん。

438 ：_：03/08/04 02:23

http://homepage.mac.com/hiroyuki44/

439 ：デフォルトの名無しさん：03/08/04 03:29

適当に流れ読んだが・・・

結局時代は、元に戻るのか？

440 ：デフォルトの名無しさん：03/08/04 08:07

>>439
DBのオブジェクト化がさらに進んでいけば、ガラっと変わる可能性は
あるけど今は過渡期だね。

441 ：デフォルトの名無しさん：03/08/04 10:34

ビジネスロジックをすべてDB側の機能で実装
(または、java との明確な切り分けが)できれば良いが、
ロジックがjavaとストアドプロシージャに分散すると、保守が大変。
そのうえトリガなんか絡んでくると、追いきれません。
保守できるドキュメント書いてね～
テンアートニのセルベッサでは、
ビジネスロジックをPL/SQLで実装していたような・・・

442 ：デフォルトの名無しさん：03/08/04 12:45

>>439
「まずスキーマ定義ありき」なスタイルが根強くあるせいではないですか

Torqueとかのドキュメント見ると（良いか悪いかは知らんけど）アプローチが逆なようだ

443 ：429：03/08/04 15:23

意外と賛同者多いんでちょとビクーリｗ

>>432
うちはWebベースな業務系システム作ること多いんだが、
今のところOracle以外は使ったことがない。

オラクルマスターのゴールド以上がそこらじゅうにいるような
会社だから、他のDBで提案する事がありえないのもあるけど。

そうじゃなくても、業務で使う可能性が高いDBって、
Oracle、DB2、MSSQL、Sybaseくらいなもんでしょ？
運用中にDB移行なんて((((；ﾟДﾟ)))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

>>441
トリガー仕掛けすぎは追うの大変だね。前に何でもかんでも
DB側でやりすぎて大変な思いしたことあるからよくわかる。

Javaのパッケージを機能単位で切り分けて、そこにリソースとして
ストプロやビューのSQLも突っ込んでる。びみょーにjarのサイズは
デカくなるが、運用する時にすぐ見つかって便利だよ。

若干スレ違いなのでsage。

444 ：デフォルトの名無しさん：03/08/04 15:33

＞そうじゃなくても、業務で使う可能性が高いDBって、
＞ Oracle、DB2、MSSQL、Sybaseくらいなもんでしょ？
うちはPostgreSQLが多い。
あとはMySQL、Oracle、DB2、MS SQLServerがほぼ同率かな。
Oracleは高いからあまり使わない。

445 ：デフォルトの名無しさん：03/08/04 17:13

で、結局
ビジネスロジックをRDBMSで処理したがるのはオールドタイプ。
なんでもかんでもJavaで処理したがるのはニュータイプ。
ってことでいいか？

http://www.namazu.org/~satoru/misc/ggap.html

446 ：デフォルトの名無しさん：03/08/04 21:27

>>445
なんでもかんでもJavaで処理したがるのは単なる厨房

447 ：デフォルトの名無しさん：03/08/04 21:39

そもそもDBトランザクションはDBに任せればよいのではないかと思うのだが
EJBのセッション／トランザクションをなぜみんなそんなに有難がりますか？

448 ：デフォルトの名無しさん：03/08/04 21:48

>>447
言いたいことはわかるんだけど
DBのトランザクションはあくまでDBだけであって
EJBのトランザクションはもっと広範囲

それらを切り分けたりするために
「Required」「Supports」等の属性ある

単純に「行って来い」的な処理ではEJBのトランザクションのありがたみはわからないし、
そこまで細かい案件にめぐり合ったこと無いと思う

449 ：デフォルトの名無しさん：03/08/04 22:07

なんだかんだいって、Entitiy Beanが一番楽だと思えるようになってきたよ。
慣れてきたせいかな。
CMRをちゃんとつかいこなして、モデルを構築し、
Session Facadeな設計にしてビジネスロジックを公開するのが、一番スマートだよ。

450 ：デフォルトの名無しさん：03/08/04 22:33

BLOBを扱いたい場合に、おすすめのマッピングフレームワークはありますか？

BLOBの取得を必要なときまで遅らせることができるとうれしいです。
今、Hibernateを使っているんですが、普通にsession.find()で取得するとBLOBまで
引っ張ってきてしまうため、わざわざカラムを指定しています。

451 ：デフォルトの名無しさん：03/08/04 22:48

>>450
遅らせるって言うのは
タイミングを指定するってことでイイのかな？

こういう機能欲しいけど無いと思う
JBossとかのEJBコンテナにこういう機能ついてるけど・・・

452 ：デフォルトの名無しさん：03/08/05 00:05

>>450
適当に自作ジョブキューに突っ込んどいて、必要になったら一斉実行とか、
一般的な遅延評価ロジックとか、そんなのを作るのは簡単だと思うんだけど。
そういう話じゃなくて？

453 ：デフォルトの名無しさん：03/08/05 01:05

PL/SQLじゃなくて、Javaでストアドがかければなあ･･･

時と場合によって好きな場所に配置できるって、よくない？

454 ：デフォルトの名無しさん：03/08/05 01:36

Oracle 8iあたりから、Javaでストアド書けたはずだけど？

455 ：デフォルトの名無しさん：03/08/05 01:39

Torque ってどうよ？

456 ：デフォルトの名無しさん：03/08/05 01:48

トルクは糞

457 ：デフォルトの名無しさん：03/08/05 01:50

>>456ﾜﾗﾀ

458 ：デフォルトの名無しさん：03/08/05 01:51

>>454
やっぱりOracleだけなのね…

459 ：デフォルトの名無しさん：03/08/05 02:08

結局、Torque を使う場合には、複雑なSQL書くには無理があるから、
VIEW なんかを使ってDB側も歩み寄れということでよろしいか？

460 ：デフォルトの名無しさん：03/08/05 02:10

>>459
よろしい。

まあ、マスタメンテみたいな簡単な操作なら、Torque はお手軽だ。

461 ：デフォルトの名無しさん：03/08/05 10:58

>459、460 利点が分からん。
java でSQLを生成するよりも、
Torqueを覚えて、設定して、view 作って、コーディングして、
のほうが効率がいいと言うの？
Torque からのDBアクセスのオーバーヘッドを無視できるぐらい、
コーディングが簡単なの？コードのメンテナンス性が向上するの？
アプリケーションを変えずに、RDBMS の製品の変更や、
OODB に変更する事ってほんとにあるの？Torque だと可能なの？
Torqueに限らず、ORマッピングの利点がぜんぜん解りません。
それは、俺がコボラーだからか？

462 ：デフォルトの名無しさん：03/08/05 12:25

>>461
実行効率をよくするためのものじゃない
DBをいかにオブジェクト的に扱うか

463 ：デフォルトの名無しさん：03/08/05 12:59

>>462
コボラなりに解ってるつもり。
実行効率はむしろ悪くなるでしょ
で、オブジェクト的に扱った先には何があるの？
SQLのチューニングは不要なの？コーディングは楽なの？
メンテナンスは？テーブルの変更は？
ってことを聞きたかった。
それよりも、SQLとビジネスロジックを切り分ける設計をしたほうが
シンプルで良いのではないか？

464 ：デフォルトの名無しさん：03/08/05 14:21

>>463

＞SQLのチューニングは不要なの？コーディングは楽なの？
＞メンテナンスは？
マッピングフレームワーク使ったときに
SQLのチューニングは出来ない
DB固有の操作はあまり得意ではない
コーディングに関してだが、これはDBマッピングというよりも
いわゆるフレームワーク全体に言えることだが
ある決まった枠の中で作業するというのは人によって窮屈でもあり
勉強しないといけないことも、多い
ただ、それは最初だけだということ。
逆に、保守の面ではフレームワークが有利だよ

＞テーブルの変更は？

これは、はっきり言ってどちらの方法でも
修正個所はある。

＞それよりも、SQLとビジネスロジックを切り分ける設計をしたほうが
＞シンプルで良いのではないか？

そんな設計的なこと、Java開発者なら誰でも考えているし、
Torque以前からアプローチは変わっていない
じゃあなぜ今Torqueや他のそういうマッピングツール使うのか・・・
アプリケーションの設計に時間かけて、あれこれﾃｽﾄなどやってるぐらいなら、
あらかじめ存在するフレームワーク使った方がイイに決まってるから
ただそれだけだよ。

465 ：デフォルトの名無しさん：03/08/05 17:02

>>463
>>464に補足するのであれば、開発人数が増えていった時に、プレゼンテーション層、
Web層、EJB層、EIS層での開発分離に役立つよ。

あと、少なくとも保守とコーディングは楽になる。
フレームワークを利用してるから開発者が変わっても対応してもらいやすいし。
SQLのメンテナンスなんて、基本的にViewの中身を差し替えればOKじゃない？

>SQLとビジネスロジックを切り分ける設計

TorqueでViewを使えばそうなるんでないかい。

そもそも設計に疑問があるなら、J2EEのデザインパターンに目を通してみればどうかな。
DAO系のパターンは、有名なフレームワークだったらほとんど利用されてると思うよ。

466 ：デフォルトの名無しさん：03/08/05 22:02

まあ、あれだ。
なんでもありよりも、縛りがあるほうが保守はラクになる。

設計書書くにしても処理を逐次記述していた部分が、
フレームワークの仕様書参照で済んだりする。
ドキュメントが減れば、そのぶんその後が引継ぎやすくなる。

467 ：デフォルトの名無しさん：03/08/05 22:48

DB厨の人は文句言うくらいなら、別に無理して使わなきゃいいんじゃないの。
別に使わなくてもできるし。

まあ、自分は毎回同じようなDAO書くのが嫌なんでTorque使うけど。

468 ：デフォルトの名無しさん：03/08/05 23:10

横からｽﾏｿ。
>>464
>保守の面ではフレームワークが有利だよ
しかし、今のフレームワークはどれも寿命が短すぎるよ
時代が下って、引き継げる開発者が果たしているかどうか。

469 ：デフォルトの名無しさん：03/08/05 23:10

>>467
つーことは、
フレームワークを使用するなら、
フレームワークはどんなDBMSにも対応できる
=DBをストレージとして使用する
のがほとんどだから
特にわざわざ高い金出してOracleでなくても
いい、ということでいいかな？

管理面（バックアップ、リカバリ、物理ファイルの増減etc．．．）
においても、有名どころの他のDBMSも同じようにできるしね。

470 ：デフォルトの名無しさん：03/08/05 23:16

Oracle が必要なのって結局は安心代でしょ。
Servletとしての基本機能は同じなのに tomcat じゃなくて、weblogic を使うのと同じで。

471 ：デフォルトの名無しさん：03/08/05 23:20

正直、Torqueだけはやめとけって
なんで日本でこんなに流行っているのかがわからん

472 ：デフォルトの名無しさん：03/08/05 23:20

>>470
>>427の意見はどう？

473 ：デフォルトの名無しさん：03/08/05 23:23

既に Oracle の技術者をたくさん抱えてしまっている企業の経営者は、
その教育コストを回収しようという発想になって、
Oracle 以外はダメよっていうだろうな。

474 ：デフォルトの名無しさん：03/08/05 23:24

>>471

> 正直、Torqueだけはやめとけって
その理由は？

475 ：デフォルトの名無しさん：03/08/05 23:25

>>472
まあ、しょうがないんじゃないんですか。
なんだかんだいって、実績 >>>>>>> 性能、価格だし。
まあ、 Oracle は性能はいいんだけど、なにせ価格が・・・。

476 ：デフォルトの名無しさん：03/08/06 00:00

>>474
透過的でないから。

477 ：デフォルトの名無しさん：03/08/06 00:02

>>471
じゃ他に何にするの？

HibernateかJDO（CasterJDOとか）絡みかな。

少なくとも日本では認知され初めてるんだから、自分が気に入らない
アーキテクチャーだからって文句付けるのはやめようよ・・・

そういえば、Strutsも最初のうちは叩かれてたね。

478 ：デフォルトの名無しさん：03/08/06 00:03

>>476
ええ・・・そんなレベルの批判？

479 ：デフォルトの名無しさん：03/08/06 00:03

>>476
何が？
ぜんぜん分かりません。
あなたはすばらしい知見をお持ちなのでしょう？
もっと詳しく教えてください。それがみんなのためです。

480 ：デフォルトの名無しさん：03/08/06 00:18

カンケーないっすけど、おまえら、オッパイ好きですか？

オレ様は、世界中の誰よりもオッパイが大好きだ。Ｄカップぐらいがいい。

481 ：デフォルトの名無しさん：03/08/06 00:32

>480
Dカップ好きは　だいぶお利口
Fカップ好きより　いくらかCOOL！
そこまで現実わかっているなら
もうひと頑張りでーす

482 ：デフォルトの名無しさん：03/08/06 00:34

・今現在、そこにあるプロジェクトを完成させるための手段。
　勝つためなら手段は選ぶな。
・将来DBのチューニングなど、アセンブラでロジックをチューンするような
　無意味なものになっていくことを見越しての、先物買い。EJB鯖が自動最
　適化してくれる…日がくるのかねえ？

後者と前者の主張が混乱してるのかもな。

483 ：デフォルトの名無しさん：03/08/06 03:11

471ではないが...

>>477
Torqueはアーキテクチャーが気に入らないって言うよりも出来が悪い。それだけ。
あと最近はそうでもないみたいだけど、ドキュメントも不親切じゃない？
フレームワーク云々、再利用云々、技術者の引き継ぎ云々議論するのもいいけど
ドキュメントや資料が貧弱じゃフレームワークとしては致命的のような気が。

それから、Sun JDOとCastorJDOはまったくの別物なのでヨロシク

484 ：デフォルトの名無しさん：03/08/06 08:21

>>483
>Torqueはアーキテクチャーが気に入らないって言うよりも出来が悪い。それだけ。
おいこら、なんで出来が悪いのか聞いてんだろ？
おまえ、小出しにしておちょくってんのかコラ？

485 ：デフォルトの名無しさん：03/08/06 09:28

え？トルクなんていまさら使ってるの？(ぷ

486 ：デフォルトの名無しさん：03/08/06 10:43

>>481
ちょっとなつかしいな。

487 ：デフォルトの名無しさん：03/08/06 11:19

>>463
考え方が逆だと思うのだが。
DBありき、SQLありきではない。

488 ：デフォルトの名無しさん：03/08/06 11:22

>>483
俺>>477なんだけど、JavaWorldで特集が組まれ始めるくらいだから
ドキュメントや資料云々の充実はこれからだと思うよ。
まだ単なる過渡期でしょ。

あと、出来が悪いってのは具体的に何？
今仕事で使ってる限り、それほど問題出てないんだけど。
なんか批判する人の多くが、単に使い方を誤ってる気がする今日この頃…

>それから、Sun JDOとCastorJDOはまったくの別物なのでヨロシク

なんでSunJDOが出てくるのかわからん、JDOの話はしてないべ。
HibernateとCasterJDOを例に出したのは俺が単に使ったことあるから。

489 ：488：03/08/06 11:24

>JDO（CasterJDOとか）

あ、ここで言ってる？もし理解が不足してたんなら謝るよ。
本題はTorqueの話ね。

490 ：デフォルトの名無しさん：03/08/06 11:53

つかフレームワークつかっててドキュメントに満足したことないんだけど。
あんまり良いものつかってないせいかもしれんが。

491 ：デフォルトの名無しさん：03/08/06 13:27

Hibernateマンセー
Torque使ってるﾔｼは負け犬かﾁｮｿ

492 ：デフォルトの名無しさん：03/08/06 14:46

>>490

monazilla Part 4
http://pc2.2ch.net/test/read.cgi/tech/1042432238/846

皆考えることは一緒って事でしょうかね。

493 ：デフォルトの名無しさん：03/08/06 16:05

>>491
両方を使いこなせてないなら、お前も負け犬では？

494 ：483：03/08/06 17:18

>>488
Torqueがまだ過渡期だってのには同意するけど、Hibernateだったら
既に充分すぎるほどのドキュメントが揃ってるわけで。
Torqueは、必要最低限の利用法をカバーしたTutorialと
(シンプルすぎる)User's Guideくらいしかないでしょ？
Undocumentedな部分が多すぎて、挙動を確認するために
逐一ソースを追っていくのがダルいです。

495 ：483：03/08/06 17:30

で、俺がTorqueの出来が悪いと思っているのは以下の点。
ただ、去年検証してダメ出ししたっきりなんで、間違ってる点や
既に解決している部分もあると思う。それらについては指摘しておくれ。

OUTER JOINがサポートされていない。

JTAに対応してないみたい。

オブジェクトを更新した際、明示的にsave()メソッドを呼ぶか
PeerクラスのdoUpdate()メソッドを呼ぶ必要がある。
→透過的じゃないやん

あらかじめ設定したJDBCコネクションしか使わせられない。

自動生成されるクラスが多すぎる。
クラスFooに対して、FooPeer、BaseFoo、BaseFooPeerって…。
クラスを自動生成する都合上、BaseFooが出来るのまではわかるが。

オブジェクトを1つだけ取得したい場合でもBasePeer.doSelect()に
Criteriaを渡して、結果をリストで取得しなければならない。
これじゃダサすぎ。
List result = FooPeer.doSelect(criteria);
Foo foo = (Foo)result.get(0);

(続く)

496 ：483：03/08/06 17:31

(続き)

Eclipse用プラグインが無い。
XDocletがTorqueだけサポートしていない(HibernateとCastorは
サポート済)。いちいちマッピングを手書きするのは面倒です。

足周りのVillageがさっぱりメンテされていない。
なんとなく不安。

プロジェクトに組み込む際に必要な下準備が多すぎる。
Hibernateだったら、データクラス毎に*.hbm.xmlを用意して
hibernate.propertiesをクラスパスに置けばOK。

まあ、上記の３つはどうでもいいような気もするが。

497 ：デフォルトの名無しさん：03/08/06 17:48

JDOを使ったことのある人に聞きたいんだが、
パフォーマンスはどうよ？

いくら過渡期とはいえ、これからパフォーマンスが大幅に
改善されることはないと思うのだが．．．

498 ：デフォルトの名無しさん：03/08/06 18:37

>>497
Jakartaもまだ完璧JDOじゃないし・・・
トライアクティブとか言うやつ試したけど

っていうかパフォーマンスの意味わかんない

499 ：デフォルトの名無しさん：03/08/06 19:57

>>483
いや、だからTorqueの作りがダサいってのは別に否定してないわけで・・・
そもそも、アナタが文句をつけているのはアーキテクチャーの話じゃないの？

「出来が悪い」って、「バグバグで使えない＋最低限必要な機能が存在しない」って
意味かと思ってたよ…
OUTER JOINはそもそもView使っとけば良い話だし、JTAに関しては対応せずとも
通常のConnectionを利用したTransaction管理が行えるから、最低限の機能は満たしてる
んじゃないかな。
他はそれこそTorqueのアーキテクチャーに文句をつけてるだけでしょ。

俺もHibernateは好きなんだけど、ほんとに日本でドキュメント充実してると思ってる？
ためしにgoogle[日本語]でHibernate javaとTorque javaの検索件数を比較してみてごらん。
どっちも少ないけど、Hibernateの使い方なんて特に少ないでしょ。
※俺の現場では英語を読もうとしない技術者の人が多いから、とてもじゃないけど
　Hibernateは導入できん。（TorqueはWeb+DBの記事とWebを見せてやらせてる）

500 ：483：03/08/06 20:47

>>499
例えば、単一のオブジェクトを取得する手段が提供されていないってのは
アーキテクチャレベルの話じゃなくて、作りがダサいってことにならないかな。

それから、俺は日本語のドキュメント云々なんて話はしてないです。
そもそもTorque使おうってのに英語のドキュメント読まないで仕事になる？
だから>>494でも「Hibernateの英語ドキュメント」と「Torqueの英語
ドキュメント」について*のみ*比較してたんだけどなあ。

Torqueマンセーなのは日本の雑誌記事ばっかりで、日本のサイトをぐぐった
限りではTorqueを褒めてるサイトがひとつも見つからないってのが
そのままTorqueの現状を表してるでしょう。

501 ：デフォルトの名無しさん：03/08/06 21:08

>>500
いや、まあ最初から英語ドキュメントで比較してるのは分かってた
んだけどね…

でも日本での普及って点を考えると日本語ドキュメントで比較するのが
普通でしょ。だから好みがどうあれ日本ではTorqueの方が主流になる
可能性は高いよ。

>そもそもTorque使おうってのに英語のドキュメント読まないで仕事になる？

システムの基本実装する人（アーキテクト）だったら仕事にならない。

でも、個々の限定されたプログラムレベルであれば、Torqueの日本語ドキュメント
程度のものがあれば、十分仕事をすることが可能だと思うよ。

最近の現場は派遣社員の質も含めて相当低くなってるよ。
英語のサイトを見ようともしない人もざらにいる。
だから日本語ドキュメントの充実は技術を導入する上で必須だと思う。
※アナタが少数精鋭の会社にいるんだったらごめんなさいね
　結構俺は短期派遣の若い人と組まされるのが多いので…

502 ：501：03/08/06 21:20

ちょっと話がORMからはずれてきてしまったので自粛します。

>>500さんに誤解の無いように言っておくと、Hibernateは好きです。
ただ現時点で通常のプロジェクトで使わせてもらえるかは別の話って事で・・・
※2,3人の規模だったら是非使ってみたいと思ってます。

503 ：デフォルトの名無しさん：03/08/06 22:14

Hibernateも全部日本語化してくれないかなあ。

504 ：デフォルトの名無しさん：03/08/06 22:19

Criteriaとほとんどおなじアーキテクチャのライブラリは2年程前に作ったな。
俺ライブラリだというのもあったが、かなり楽ができる機能だ。

動的に検索条件を構築するならあのくらい簡潔なほうがいいな。
作るのにかかる労力に比べて、「あると便利度」がかなり高い。

505 ：デフォルトの名無しさん：03/08/07 01:00

英語を読もうとしないｷｬﾂがｵｰﾌﾟｿなんてやるんじゃねーよ。

506 ：_：03/08/07 01:01

http://homepage.mac.com/hiroyuki45/hankaku10.html

507 ：デフォルトの名無しさん：03/08/07 01:02

英語読めてHibernateの良さがわかる奴が、日本語の説明文書いてあげればいいのでは？

日本語ドキュメントが無いのを理由に採用を躊躇してしまう事を、怠慢と取るか
不幸と取るかで変わってくるだろうけど、少なくともTorque陣営は、
ドキュメントの日本語化によって、日本での利用者拡大に成功していると思う。

我々は、英語の文章を読むことが仕事じゃないんだし、むしろ、それに時間を
とられて技術的なことをする時間を削らなければならないのは不幸だと思う。
使う人がいちいち翻訳するのが当たり前だから、英語のドキュメントが充実して
いればそれで良しという考え方は違う。

508 ：デフォルトの名無しさん：03/08/07 01:12

>>505
javaが読めれば問題ない。

509 ：デフォルトの名無しさん：03/08/07 01:18

で。

うまいことORMでいい感じになったやしはいないわけですか

510 ：デフォルトの名無しさん：03/08/07 01:24

>>509
VIEW との併用でうまくいくでしょ。

511 ：デフォルトの名無しさん：03/08/07 01:28

複雑な検索条件は、VIEW＋単純な検索条件に整理。
→あとはORマッピングツール任せ。どうせどのツールでも大して変わらん。

が一番すっきり？

512 ：デフォルトの名無しさん：03/08/07 01:31

viewってなんですか？
この言葉のおかげで話の内容が見えないので誰か教えてください
どうもMVCのViewのイメージがこびりついちゃって・・・
DBのViewってどの部分なんですか？

513 ：デフォルトの名無しさん：03/08/07 01:34

>>512
ぐぐれ！まずはそれからだ。
MVCの View ではない。

514 ：デフォルトの名無しさん：03/08/07 01:38

>>513
いや、MVCのビューにかなり近い存在だと思うが。
RDBにおいて、Mが実テーブル、Vがビューでしょ。Cはなんだろ？DMLのSQLかな。

GUIでしかMVCといわないと思ってる人は屁タレｹﾃｰｲですよ。

515 ：デフォルトの名無しさん：03/08/07 01:49

>>514
それは観測者が異なるという意味で、違うでしょ？
>>512 はアプリケーション側からの視点で言ってるんだから。
文脈を無視して、屁タレｹﾃｰｲというのはどうかと。

RDBMSを観測対象の中心にすえれば君の言ってることは正しいと思うよ。
>>512 へは、モデル側から見れば、DBも永続化できるVIEWといえるとか
言っちゃうと混同してしまうかな？

まあ、あれだ。何事も多様性があるってことだ。

516 ：514：03/08/07 01:55

正直、ｽﾏﾝｶｯﾀ。

517 ：デフォルトの名無しさん：03/08/07 02:02

>>516
いや、いいんだ。

それよりも、>>512 が VIEW も知らんのに仕事になるのかと問いたい。
業務系ではないのかな？

518 ：デフォルトの名無しさん：03/08/07 05:57

>>512
ＶｉｅｗはＶｉｅｗだ。もっとわかりやすくいうなら外部スキーマだ。わかったか。

519 ：デフォルトの名無しさん：03/08/07 05:58

>>514
ぜんぜん違う。知ったかスンナ。氏ね。

520 ：デフォルトの名無しさん：03/08/07 07:07

英語で仕様書も読まないようなｷｬﾂはプログラムなんてすんじゃねーよ。
何がJavaさえ読めればいいだよ。

521 ：デフォルトの名無しさん：03/08/07 07:14

乳首みれた？
http://homepage3.nifty.com/coco-nut/

522 ：デフォルトの名無しさん：03/08/07 07:39

>>520
そうなんだけど、英語読まない奴そこら中にいるよね。
俺の隣の席のやつとかｗ

523 ：512：03/08/07 10:43

いや～あぶねぇあぶねぇ
おまいらが、あまりにも叩くもんだから
「なによViewって！」
と手元にあるポストグレスキューエルの
本かなんか見ながらView探してたよ
おいおい、かなり重要な機能ではないか

524 ：483：03/08/07 11:38

>>501
了解です。
俺も、雑誌記事の影響でTorqueが「機能的」にもベストだと
思わされている人たちに「HibernateやCastorもあるよ」と言いたかった
だけなんで、これにて終了ということで。

525 ：デフォルトの名無しさん：03/08/07 17:59

>>499

>JTAに関しては対応せずとも通常のConnectionを利用したTransaction管理が
>行えるから、最低限の機能は満たしてるんじゃないかな。

ほんと最低限だな。J2EEの中心部分使えないのダサすぎｗ
今更接続プーリングなし、自前トランザクション管理ですか？

EntityBeanが腐ってるから使いたいフレームワークなのに、
SessionBeanの最大の利点を使えないなんてな。

こんな使い方してWebLogicなんか使ってるプロジェクト
いっぱいあるんだろなぁ( ´ー`)ﾌｩｰ．．．

526 ：デフォルトの名無しさん：03/08/07 20:24

>>525
は？JTAに関してはSessionBean内でTorqueを使えばいいだけじゃん。

接続プーリングはTorque単体でもサポートしてるし、知ってる？
そして何故WebLogicが突然出てくるのかわからん。

( ´ー`)ﾌｩｰ．．．ｲﾀｽｷﾞ

527 ：デフォルトの名無しさん：03/08/07 21:08

ところで Apache OJB(http://db.apache.org/ojb/)ってのは？
これも JDO API をサポートしているようですが。

JDO がよさげで、その実装例のひとつである hibernate がよさそうってのもわかりました。
Apache OJB も JDO の実装例のひとつだと思いますが、こいつはいかがでしょう?

528 ：デフォルトの名無しさん：03/08/07 21:11

>>527
hibernateはjdo実装じゃないですよ。
Jakarta OJBもjdoってことだとまだまだらすぃ

529 ：デフォルトの名無しさん：03/08/07 21:17

だから、現時点ではトライアクティブJDOぐらいだな

530 ：デフォルトの名無しさん：03/08/07 21:18

>>528
いまいち私がよく理解していないのですが、JDO っていうのは規格(仕組み? 枠組み?ここらへんはアバウトですが)
の名前ではないのですか?

たとえばServlet というのは規格の名前であり、その実装例として Tomcat や WebLogic、Resin がある
と思っています。

JDOも規格の名前で、その実装例としてCasterJDO、Hibernate、OJB があると思っていたのですが...
あ、でも http://db.apache.org/ojb/ をよくみたら、

・A JDO compliant API
・full JDO implementation is scheduled for OJB 2.0.

ということで、JDOのフル実装はOJB 2.0 から、とありますね。
だから

> akarta OJBもjdoってことだとまだまだらすぃ

なのか。

531 ：デフォルトの名無しさん：03/08/07 21:20

>>530
規格というより仕様の気がする。

あと、HibernateはJDOとは別物じゃない？

532 ：デフォルトの名無しさん：03/08/07 21:20

ちょっと怪しいリスト。

Torque => Criteria
CastorJDO => OQL(ODMG 3.0のサブセット)
Hibernate => 独自SQL、Criteria
Apache OJB => Criteria、QOL(ODMG 3.0)、Sun JDO 1.0(不完全)
KodoJDOなど => Sun JDO

ついでに、Apache OJBは下の方でTorqueを使ってたような気がします。

533 ：529：03/08/07 21:26

>>531
> 規格というより仕様
あ、そういうこともできますね。というかそういう表現のほうが正しいかも。
Servlet API をみると、ほとんどが java の Interface ですが、
各ベンダはこの Interface をimplements すれば、Interface で宣言されている仕様を実装していることが
保証されているので、仕様にのっとっている、ということもできるでしょう(あくまでもコンパイルレベルですが)。

オブジェクト指向の、正しい「機能と実装」の考え方だな。

JDBC もそうですが、OracleのJDBCドライバのように、サポートに問い合わせてみると「その機能は未実装です」
とか返事が返ってくるのはむかつく。

ちなみに Sun JDO って http://java.sun.com/products/jdo/ のことだよね？
こいつの実装例として、>>532 の Kodo JDO っていうことなのかな？

Hibernate はこれからみてみます。

あと >>530 も私です。

534 ：デフォルトの名無しさん：03/08/07 21:26

>>530
JDOってのはSunの仕様の名称であると同時に、オブジェクトとデータベースの
マッピング手法の代名詞的な扱いもされているので、仕様であるJDOを指す時は
Sun JDOとかSun's JDOみたいな表記をすることが多いです。

特にCastorJDOなんかは、CastorXMLという兄弟がいるので便宜上JDOを
付けて呼ぶことが多いです。

こう書くとわかりやすいか？
JDOは「RDBMS」
Sun JDOは「SQL92」
CastorJDOは「RDBMSっぽいけど仕様は別なもの」
商用のJDOエンジンは「SQL92フルサポートなRDBMS」

535 ：デフォルトの名無しさん：03/08/07 21:33

>>534
ぜんぜん

536 ：529：03/08/07 21:36

>>534
うーん、なんとなくわかってきたような... どうもありがとう。
ちなみに Servlet(の仕様)というと、Sun の Servlet という使用があるわけだが
(Servlet サポートという場合、Servlet API を実装していなければならないですよね?)、

JDO の仕様は Sun の JDO 以外にもあるの？

537 ：デフォルトの名無しさん：03/08/07 21:40

べつに、細かい話なんてどうでもいい
はっきりいって話題が違う

538 ：デフォルトの名無しさん：03/08/07 22:48

＞＞１ >>5 >>10

539 ：デフォルトの名無しさん：03/08/08 01:34

HibernateをWebアプリで使ってるんですが、いちいち
HibernateのSessionを開いて、閉じて、例外処理を行うあたり、
JDBCをコーディングしているのとそんなに変わらないような
気がします。

この点についてはどう思いますか？　Hibernateのサイトでは
フィルターを使って開け閉めを行えばいいみたいなことが
書いてありますが、あまりスマートじゃないような。

540 ：デフォルトの名無しさん：03/08/08 06:26

>>539
>>1-1000

541 ：デフォルトの名無しさん：03/08/08 06:34

>>540
>>1-10

542 ：デフォルトの名無しさん：03/08/08 06:34

>>1-5

543 ：デフォルトの名無しさん：03/08/10 00:39

TorqueはSQL作ってくれたり、HTMLのDBドキュメントを生成してくれるから
Javaに限定されず、それなりに需要はあると思うんだけど…

Javaでの実装時はHibernateの方がシンプルで良さそうだね。

544 ：デフォルトの名無しさん：03/08/10 14:51

外部ソース(DBとかファイル)の扱いを、抽象度の高いクラスで
ラップすればいいだけでは？
それだと、Torqueだろうが、Hibernateだろうが、JDBCゴリゴリだろうが、
CSVファイルだろうが、カンケーない。
むしろ、設定ファイルの管理やOuterJoinできませんなんて馬鹿な制限がない分、
JDBCゴリゴリをラップしたほうがシンプル。
ま、俺様フレームワークになることは、確実だと思うが。

545 ：(゜Jし゜)：03/08/10 19:50

Javaじゃなくて.NetFrameWorkですが、
ADO.Netではこの辺はどんな感じなのでしょうか？

DataSetを持ってきてCommandBuilderにSQL自動生成させて、
ってのは標準でORマッピングっぽいことが出来るような
気がするんですが

546 ：デフォルトの名無しさん：03/08/11 00:07

>>545
その場合プログラマはDataSetという非ドメインオブジェクトを意識することになるので、
ORマッピングとは言わないと思われ。
java.sql.Statement#executeQuery()の戻り値が、HashMapを持ったArrayListになって、
データの更新をラップするメソッドが提供されるようなものかな。
（API的には間違っているけど、概念的にはあってると思う。）

547 ：デフォルトの名無しさん：03/08/11 02:42

>>544
OuterJoinをSQLでやらずにViewでヤットケというのが、今の潮流のようですが…

548 ：デフォルトの名無しさん：03/08/11 07:15

>>547
そんなばかな。
今のO/Rマッピングのフレームワークがいけてないだけ。

549 ：デフォルトの名無しさん：03/08/13 11:31

JDO開発者＆ベンダーコミュニティJDOCentralにSunが参加。
http://biz.yahoo.com/prnews/030812/latu050a_1.html

550 ：山崎渉：03/08/15 15:34

　　　 (⌒V⌒)
　　　│ ＾＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン

551 ：デフォルトの名無しさん：03/08/16 22:28

一応、コレの%HOME%\demo.batは正常に動くのでデータベース設定等は正しいみたいです

552 ：デフォルトの名無しさん：03/08/17 18:04

>>551
マジで!?

553 ：デフォルトの名無しさん：03/08/18 21:00

ああ、setupコマンド打てばいいのか・・・

554 ：デフォルトの名無しさん：03/08/25 13:25

軽く保守

555 ：デフォルトの名無しさん：03/09/01 13:44

age

556 ：デフォルトの名無しさん：03/09/10 15:19

Hosh

557 ：デフォルトの名無しさん：03/09/10 16:10

重く保守

558 ：デフォルトの名無しさん：03/09/15 22:52

ネタ無いねー

559 ：デフォルトの名無しさん：03/09/18 22:21

Hibernate joins JBoss
http://hibernate.bluemars.net/136.html

560 ：デフォルトの名無しさん：03/09/18 22:42

>559
これって喜んでいいの？
悲しんだらいいの？
JBossは使ってなくて、Hibernateは使ってるんだけど。

561 ：デフォルトの名無しさん：03/09/18 23:46

ここまでの俺流あらすじ（Javaの知識は基本以外はないので客観的に見れてるはず）

各フレームワーク

俺様フレームワークはオナニーだな。一生てめえが面倒見ろよ
Torqueはださい、つかいづらい。でも流行ってるからつかおうぜ
HibernateはJDOだから将来性あり。でもそれなりに癖あるぜ
その他　なんかよくわかんなーい。でもそんなマイナーなものつかわんでいいじゃん

設計とか

Viewで外部結合はなんとしろ。じゃないとほとんどのフレームワークむりぽ
OOとRDBは相容れないもんだから、頑固にOOは頭硬いYO
SQLをソースに埋め込む埋め込まないは個人の経験によりけり
チームメンバーは自分と同スキルでないのでそこんとこよろしく

総評

この先JDOが主流になる予感。癖のあるフレームワークでガチガチになるなよ

個人的な意見

全然わかんないんだけどSunJDOがそのうちSDKに組み込まれんじゃないの？
だったらそれに準拠してるの使うかそれまではJDBCをちょろっとラッピングしてればいいのでは？
デザインパターンとかでそういうのあればいいすねぇ

保守age

562 ：デフォルトの名無しさん：03/09/19 12:33

>>561
HibernateはJDOの実装ではないと思うのだが

あと、JDO1.0はORMとしてはかなり萎える面が多いと思うのだが気のせいだろうか？
ORMだったら当り前っぽい機能でも「実装依存」扱いになっているものが多くないか？
JDO2.0でそこら辺もうちょっと考えてくれる方向性っぽいのでそれには期待してたいと
思っているけど

563 ：デフォルトの名無しさん：03/09/21 21:28

Hibernateも(ついでに)CastorもSunのJDOとは無関係ですね。

564 ：デフォルトの名無しさん：03/09/25 22:24

いまさらなんですが>>405の理由を教えてください

565 ：デフォルトの名無しさん：03/09/26 01:35

WebObjectsのEOFさわらないで、O-Rマッピングを語るとは笑止千万。

＃いや、マジでさわってみてって。業務で使わないにせよ。

566 ：デフォルトの名無しさん：03/09/26 01:54

>>565
WebObjectsって工数は削減できそうなんだけど、例えば結果に
含まれる行が大量になるデータの扱いとかが苦手という話なので
使う気にならん。性能的にどうなの？

WebObjectsって、ページデザインをデザイナーが担当するような案件の
場合にすごい作業しにくそうなんだけど、EOF部分だけをStrutsや
Tapestryなどのフレームワークと組み合わせて使えます？

567 ：デフォルトの名無しさん：03/09/26 03:05

>>566
あー、大量データはきついかもねぇ。
EOFといっても所詮はキャッシュだからねぇ。

> EOF部分だけをStrutsやTapestryなどのフレームワークと組み合わせて使えます？
PureJavaだから、使えると思うよ。やったことないけど。
でも、WOF（WOで使うWeb周りのフレームワーク）を使わないように気をつけないとね。
でも、すみません、Tapestryはしらない。WOの影響を受けてつくったらしいとかいううわさは聞くけど。

568 ：リカバリ：03/09/26 03:22

どなたかデータリカバリの良いソフトをご存じないですか？
デジカメで撮った写真、動画のデータ及びexcel等の重要なデータを誤って消してしまったのです。
出来ればフリーソフトであるといいのだけれど・・・

569 ：566：03/09/26 12:24

>>567
回答サンクス。
まあ、EOFだけ抜き出して使うなんてキチガイじみたことは
やらないと思うけど、機会があったらWebObjectsもやってみたいねえ。

570 ：デフォルトの名無しさん：03/09/26 17:55

Torqueなんですが、autoincrementなどでIDの自動生成をするテーブルが
あったとして、INSERTしたと同時にその自動付加されたidの取得ってどうすれば
よいでしょうか？
ご教授お願いいたしまそ。

571 ：デフォルトの名無しさん：03/09/26 19:32

>>570
もうtorqueは使わなくなったので間違ってるかもしれんけど、
dataObject.save();
Integer id = (Integer)dataObject.getPrimaryKey();
みたいな感じでどう？

572 ：デフォルトの名無しさん：03/09/26 20:36

>>571
さんくす！一度やってみます＾＾

573 ：デフォルトの名無しさん：03/10/02 20:49

HoshAge

574 ：デフォルトの名無しさん：03/10/03 00:00

>>573
このスレ上げる意味って何よ。
DB板も悲惨じゃない。

575 ：デフォルトの名無しさん：03/10/03 00:35

ｱｵﾘﾆﾏｼﾞﾚｽｶｺﾜﾙｲ
ﾓﾚﾓﾅｰ

576 ：デフォルトの名無しさん：03/10/03 13:50

みんな！
Torqueかけて行くぞ！

577 ：デフォルトの名無しさん：03/10/04 04:44

WebObjectはパッケージングがしにくいな。
俺の技術のせいかもしれないけど。

578 ：デフォルトの名無しさん：03/10/07 05:39

Torque提案したら却下されたよぉ・・・・(/Д`)・゜・
なんで自前で作らなきゃいけないんだよぉ･･･
途中から訳ワカメ状態に陥ってただのDBアクセッサになりつつある罠。

漏前ら自前で作った(事がある人で)RDBフレームワーク or アクセッサ設計晒してもらえます？
自分は個人的にC++のDBTools好きだったんで、それに近い感じで作ってます。

579 ：デフォルトの名無しさん：03/10/07 06:00

>>578

必要なときにデータをとってきて必要なときにインスタンスを作る。それ以外方針なんてありようがない。設計ったってそのときどきによるよ。

580 ：デフォルトの名無しさん：03/10/07 07:40

>>578
却下された理由って何よ。
他のフレームワークは提案したのか?

581 ：デフォルトの名無しさん：03/10/14 00:03

>>578
Torque はWHERE句の条件の順序を指定できないぞ。
INDEX利かんぞ。それでもいいのか？

582 ：デフォルトの名無しさん：03/10/14 22:41

>>581
INDEX利かない？

583 ：デフォルトの名無しさん：03/10/14 23:25

索引使わんのか。しょぼすぎる

584 ：デフォルトの名無しさん：03/10/15 07:41

>>581
from句じゃなくてwhere句の記述順序を特定できないと
困るDBMSってなんだっけ？

585 ：デフォルトの名無しさん：03/10/15 21:16

>>584
ふつうWhere句は後ろから評価するじゃない。
だから効率いい評価を逆順で書くけど、そりができないってことでしょ

586 ：デフォルトの名無しさん：03/10/15 22:24

>585
普通のDBMSは後ろから評価するものなんですか？
OracleもDB2もSQLServerもPostgreSQLもMySQLも、みんなそうですか？

587 ：デフォルトの名無しさん：03/10/15 23:16

>>586
ネタに釣られるなよ。
そんなことはない。
今時のRDBMSはけっこう賢い。

588 ：デフォルトの名無しさん：03/10/16 21:06

>>587
まじですか？結構意識して書いてたのに
oracleだと私が使ったことあるのは8.0.6～8.1.7なんだけど、いつぐらいからそうだったんですかね？

589 ：デフォルトの名無しさん：03/10/16 23:07

あるテーブルの複数のフィールドに条件指定する場合、選択性の
高い(=falseになりやすい)フィールド条件が先に評価されるよう記述
した方が効率が良いということかな？
実行計画の決定に比べたら屁みたいなもんなんで、気にしたことが
なかった。

590 ：デフォルトの名無しさん：03/10/17 09:11

>>589
DBMSによるけどじゅうようだよ。
データによって偏りがある場合、それで最初に絞ったほうが早いかどうかって。
最初に評価されるはずの条件でデータが一気に絞れたり、それにたいしてINDEXを使えるかとか。

591 ：デフォルトの名無しさん：03/10/17 22:31

>>590
インデクスが使えるかどうかってのはたしかにすごく重要だ。

けど、それがwhere句の記述順序で決まるようなアホなDBMSは
いまどき存在しないだろう。
sequencial scan で選択条件が複数ある場合にちょっと効くかな？
という程度じゃないか？

592 ：デフォルトの名無しさん：03/10/22 19:05

「Patterns of Enterprise Application Architecture」
http://www.amazon.co.jp/exec/obidos/ASIN/0321127420/qid=1066816704/sr=1-2/ref=sr_1_18_2/249-7197900-6499567

↑読んだ人いませんか？非常に気になっています。

データベースマッピングについての記述はどのようなものでしょうか？
SQL文を直接書くことを前提にした設計でしょうか？
それとも、TorqueやBC4Jなどのフレームワークを使用した設計のパターンでしょうか？

私は接続に関するオブジェクトをクラス間で渡し合い、
しっくりこない設計をしているのですがきれいなパターンを知りたいと思っています。

593 ：デフォルトの名無しさん：03/10/24 15:34

>>592
よみました。

2/3くらいがORマッピングの話だったかと。

紹介されているパターンについては著者のサイトを参照してください。
http://www.martinfowler.com/eaaCatalog/
SQLを直接書くパターンから抽象的なマッピングフレームワークのパターンまで
いろいろとりそろっています。

torque, bc4jなどの特定のフレームワークを利用した解説はされていません。
どちらかというと、そういったフレームワークをつくるときに問題となる事項や
利用できるデザインパターンについての解説って感じです。

接続に関するオブジェクト云々に関しては、
今ホットな話題のIoCなコンテナである
Spring Frameworkとかを調べてみるのもいいんではないでしょうか。

594 ：593：03/10/24 16:51

>>593
レスありがとうございます。

> torque, bc4jなどの特定のフレームワークを利用した解説はされていません。
> どちらかというと、そういったフレームワークをつくるときに問題となる事項や
> 利用できるデザインパターンについての解説って感じです。
そうなんですか。
よくわかりました。私は一からそのようなフレームワークを作る気はなく
既存のものを利用したいので、この本はあまりやくだたないでしょうか？
あるいは、フレームワークを深く理解するためにもそれなりに有益でしょうか？

>
> 接続に関するオブジェクト云々に関しては、
> 今ホットな話題のIoCなコンテナである
> Spring Frameworkとかを調べてみるのもいいんではないでしょうか。
IoCもSpring Frameworkもしりませんでした。調べてみます。

どうもありがとう。

595 ：デフォルトの名無しさん：03/10/25 21:11

>>591
Oracleはそうなわけだが。。

596 ：デフォルトの名無しさん：03/10/26 00:31

>>595
んなアホな。PostgreSQLだってもっとマシなプランナ持ってるよ。

記述順序が効くとすれば、どの条件でもインデクスが使われないか、
CBOを使っていてかつどの条件でもインデクスが使える場合だろう。

597 ：デフォルトの名無しさん：03/10/26 12:40

>>596
設計思想が違うだろうから単純比較はできないんじゃない？

漏れの記憶ではOracle8iとかではWHERE句に書く順序は気にしてたはず。
オプティマイザがルールベースだったかコストベースだったかは覚えてないけど。

598 ：596：03/10/26 13:31

>>596
間違えた。CBOじゃなくてRBO。

>>597
少なくともRBOの場合、インデクスが使える条件は使えない条件より
優先されるから、そんなことはないはず。記述順序で決まるとすれば、
どちらもコスト的に等価とみなされた場合だけ。
逆にそれらがみんな記述順序で決まるとすれば、オプティマイザの
仕事がなくなってしまうし。

599 ：597：03/10/26 19:13

>>598
ああ、ごめん。漏れの記憶の話はインデクスを使う話とはぜんぜん関係ない話だった。
逝ってくる。

600 ：デフォルトの名無しさん：03/11/02 01:30

RDBではテーブルとテーブルを結合するにはキーとなる情報が必要だが、
OOでは普通クラス間の関連で表現するよな。

一方のクラスが片一のクラスのインスタンスを包含する場合、
このスレで取り上げられたJDOやらなんちゃらのFrameWorkでは、
どうやってそれを実現してるんだろう？
（オブジェクトのシリアル値をテーブルに含めるとか？）

601 ：デフォルトの名無しさん：03/11/05 20:27

age

602 ：デフォルトの名無しさん：03/11/09 14:37

「WebObjectsのEOF使いたいけど、Appleはなぁ・・・」と思ってるﾔｼ
Cayenneを使ってみれ
http://objectstyle.org/cayenne/

603 ：デフォルトの名無しさん：03/11/09 22:36

>>602
興味あるなー。詳しく説明して。
Tapestryと組み合わせたらWOもどきの出来上がり？

604 ：デフォルトの名無しさん：03/11/11 04:41

>>602
この手のツールを使ったことが無かったんだが興味があったんで落としてみたが、
結構便利そうね。DBMSのスキーマ情報のリバースとか、DAO層のJavaクラスを
自動生成してくれたりとか、リレーションをリバース時にも自動で解決して
くれたりとか。欲しい機能は揃ってる感じ。
ちょっと気になったのが、PKのGenerationまわり。
従業員番号やISBNみたいに、エンティティとして意味のある値がPKでない
場合、DBMSの機能で自動生成させることが実際には多いと思うのだが、
その方法ってモロにDBMS依存だよな。Oracleのシークエンスには対応
してくれてるみたいなんだけど、MSSQLのIDENTITY列には対応できなさそうな
気が。PKの値が与えられていない場合は自分で値を捏造しちゃおうと
するみたいだしな。
この辺、別にCayenneに限らない問題と思うのだが、一般的にはどう
解決されてるのかしら。そういうDB設計は、避ける？

605 ：デフォルトの名無しさん：03/11/12 01:10

>>604
JDOも2.0からはPK生成を対応するみたいです。
実装方式に関しては、不明ですが。

606 ：604：03/11/12 06:27

>>605
CayenneでのGenericなPK生成の方式は、テーブルにシード値を格納しておいて、
それをインクリメントしながら生成するという単純な遣り方。
後は個別のDBMS向けに、もっとマシな実装が用意されている場合もある。
ま、この方式にしろ、行ロックは必須だし、DBMS依存性はやはり残る。

柔軟性という意味では、アプリケーションレベルではDBMS毎のアダプタ実装を
プラグインできるのだが、本来はもう少し細かくテーブル単位でカスタマイズ
したいところだ。Oracleのシークエンスにのみ、個々のテーブル単位での
カスタマイズに対応しているようなんだけれども。

607 ：デフォルトの名無しさん：03/11/14 22:01

>>604
例えばTorqueだとID用テーブルを作ってそこでSEQUENCEのようなことをする（こともできる）。
606と同じだね。
MySQLの場合の例
CREATE TABLE ID_TABLE
(
ID_TABLE_ID INTEGER NOT NULL,
TABLE_NAME VARCHAR (255) NOT NULL,
NEXT_ID INTEGER,
QUANTITY INTEGER,
PRIMARY KEY(ID_TABLE_ID),
UNIQUE (TABLE_NAME)
);
で、これを管理するためのクラスもある。

多分他も同じようなものじゃないかな。
自分で作るとしてもこうするし。

608 ：デフォルトの名無しさん：03/11/15 01:01

Torqueで質問です。
ランタイムのコード（Peer）を読んでたら、doUpdateとかで最後にTransaction.commit()
みたいになってたんですけど、これって、オプションかなんかではずせますか？
複数テーブルの更新でまとめてコミットするような処理って無問題？

609 ：デフォルトの名無しさん：03/11/21 22:12

WebObjectsのEOF ってwindowsで評価版とかありますか？
MacOSXとSolarisだけしか使えないのかなー。

610 ：デフォルトの名無しさん：03/11/22 02:28

いっそ富豪的にPrevayler使うってのはどうよ（ｗ

611 ：デフォルトの名無しさん：03/11/22 15:59

>>608
doUpdate(criteria, connection)の方を使って、connectionのautoCommitを
falseにしておけばできると思います。

612 ：デフォルトの名無しさん：03/11/25 20:33

このスレであっているかどうかわからないけど、詳しそうな人が一杯いると思うので
質問です。

Oracle の JDBC ドライバは、OCI(type2)と thin(type4)の両方がありますが、
Oracle 以外で type2 ドライバってあるの？

postgresql.jar とか MySQL 用って、みんな type4 だよね？
これらふたつや DB2 用のドライバに、type2 ってあるのですか？

613 ：デフォルトの名無しさん：03/11/25 23:14

>>612
DB2にはあるぞ。

↓ちょっと古いけど・・・
www-6.ibm.com/jp/software/data/developer/library/techdoc/javappli.html

614 ：デフォルトの名無しさん：03/11/26 00:25

つーか、このスレで間違っているのでは？

615 ：デフォルトの名無しさん：03/11/26 19:26

OR Mapping と言えるかどうかわからないけど、Jakartaでこんなものがリリースされたみたい。

Jakarta Commons-DbUtils
http://jakarta.apache.org/site/news.html#20031111.1
http://jakarta.apache.org/commons/dbutils/

DbUtils is a small set of classes designed to make working with JDBC easier.
ということらしいので、本格的な、大規模のアプリケーション等で DB アクセスをラッピングする
フレームワークというよりは、
JDBCプログラミングを生でする代わりに少し楽をする、という目的なのかな。

サンプルをみてみたが、あまりイケてる実装には思えなかったが...
クラスもまだ 17コしかない。

とりあえずご参考までに。

616 ：デフォルトの名無しさん：03/11/26 22:04

>>615
これ新しいの？
この前たまたま見かけて、オレもサンプル読んだ程度だけど、
ちょっと変わってて面白いと思った。

617 ：デフォルトの名無しさん：03/11/26 22:21

>>616
変わっているというか、誰でもやってることをCommonsプロジェクトが
やってくれた、という感じ。
いつも、みんなやっているよね。
毎回毎回作っているよね。
それなら、ライブラリ化しよう！
いつでもどこでもみんな同じモノを使えるよ！
ってとこかな。

618 ：デフォルトの名無しさん：03/11/26 22:28

WEB+DBに載ってたseasarってあｐ鯖の
SqletってORマッピングが結構気に入った.
SQL書くのが気にならないなら便利かも,

619 ：615：03/11/26 23:09

>>616
> これ新しいの?
たまたま jakarta のサイトを見ていたら、1.0 release と出ていたから、新しいものなのかと思った。
えらそうなことを 615 で書きましたが、今回はじめて知りました。
beta のころからずっと知られていたものなのだったらすみません。
ちなみに 11/10 付けのリリースだそうです。

620 ：615：03/11/26 23:11

さらに間違ってしまいました。
誤：11/10
正：11/11

621 ：デフォルトの名無しさん：03/12/05 16:55

Torqueでcount(*)ってどうやってとったらいいの？
全件ならリストサイズなんだけど、GROUP BYかけてグループごとの件数を知りたい場合の話ね。
やっぱりループでぐるぐるカウントするしかないの？

622 ：デフォルトの名無しさん：03/12/06 00:46

spring frameworkの話題はもうないの？

623 ：デフォルトの名無しさん：03/12/06 17:21

621>>
criteria.addSelectColumn( "count(*)" );
Record result = (Record) HogehogePeer.doSelectVillageRecords(criteria).get(0);
int count = result.getValue(1).asInt();

624 ：デフォルトの名無しさん：03/12/08 14:06

おお！
Village使うのか。このあたりよく知らなかったよ。
ありがとう。
いい人だ>>623

625 ：デフォルトの名無しさん：03/12/12 11:13

Hibernate 2.1 が出たよ

626 ：デフォルトの名無しさん：03/12/12 15:17

>>625
- native SQL queries
- full Criteria query API, with support for associations
- integration of OSCache, SwarmCache, JBoss TreeCache, as well as EHCache.
- more "cool" features.

普通のSQLも書けるようになったみたいね

627 ：デフォルトの名無しさん：04/01/07 17:35

Hibernateで「表」っていう漢字で終了する文字列がDB追加できないんですが・・・

628 ：デフォルトの名無しさん：04/01/08 00:45

『表』問題なんて、プログラマーなら誰でも知ってるだろ…
Hibernateは関係ないぞ。

629 ：デフォルトの名無しさん：04/01/08 02:33

>>628
\が入ることしかしらん。
なんでHibernateが関係ないとなるのか、わからん。

630 ：デフォルトの名無しさん：04/01/08 08:54

>>629
関係ないの表現のとり方を間違っている。
６２８のいいたい関係ないは、固有の問題じゃないということ。

631 ：デフォルトの名無しさん：04/01/08 12:12

Hibernate使ってても使って無くても、そういう文字は
エスケープするよねということですよ。はい。

632 ：デフォルトの名無しさん：04/01/08 13:22

>>631
ようするに、Hibernateは自動で対処してくれないということだな

633 ：デフォルトの名無しさん：04/01/08 14:00

627です。
無知でした・・・
どうもありがとう。

634 ：デフォルトの名無しさん：04/01/08 20:38

>>632
開発チームにそういう要望を誰もコミットしてないからだろ。
頼まれてもいない全言語ですべての文字が文字化けしないか誰が試すんだよ。

635 ：デフォルトの名無しさん：04/01/08 20:43

>>634
普通に\入れたときはどうなるの？

636 ：デフォルトの名無しさん：04/01/13 20:24

>>635
当たり前だけど普通にJavaで\使ったときと同じ。

637 ：デフォルトの名無しさん：04/01/14 06:25

>>636
普通にJavaで\使ったときとは？
文脈からいえば
　PreparedStatement#setString
のとき？

638 ：デフォルトの名無しさん：04/01/14 21:46

"\"hoge\""

"価格は\\4,000"

みたいな感じだろ。

639 ：デフォルトの名無しさん：04/01/15 01:09

それじゃ"表示"が文字化けすることにはつながらんね。

640 ：デフォルトの名無しさん：04/01/15 14:05

>>639

>>635 >>636 >>637 >>638
↑
どこに”表示”に関しての話が出ておる？

641 ：デフォルトの名無しさん：04/01/16 10:25

>>640

>>627
表示じゃなくて表でおわるだったけど。

642 ：デフォルトの名無しさん：04/01/16 15:26

>>641
表示に関してでも表で終わる文字でもなく、\という文字を普通に
Hibernateに渡したらどうなるかと言う質問以外には読み取れないのだが、どうよ？

643 ：デフォルトの名無しさん：04/01/17 04:42

>>640
本題はそこじゃなかったことに気づけ。
も少し前から話が始まってるだろ。

644 ：デフォルトの名無しさん：04/01/17 12:42

639の書き込みが、どの話題に対してのレスなのか
明記されてないから、みんな直前の話題だと思って
いるのだろう。まぁ、書いた本人は脳内で違う話題に
レスをしているので、話がかみ合わなくなっている。

645 ：デフォルトの名無しさん：04/01/17 14:22

で、Hibernateで表がはいらないのは解決したのか？

646 ：デフォルトの名無しさん：04/01/24 19:40

R-Oマッピングをつくりませんかとの掛け声で奴が立ち上がった！
ttp://homepage2.nifty.com/igat/igapyon/diary/2004/ig040121.html

……だめぽ

647 ：デフォルトの名無しさん：04/01/26 09:02

>>646
誰かTorqueを教えてやれよ

648 ：デフォルトの名無しさん：04/01/27 22:26

テーブル名が日本語だろうと、項目名が日本語だろうと何の問題もなく使えるやつなら作ってくれ。

649 ：デフォルトの名無しさん：04/01/28 10:18

英語使えよ

650 ：デフォルトの名無しさん：04/01/28 11:20

>>648
ローマ字にすればいいのに。

651 ：デフォルトの名無しさん：04/01/28 22:00

>>649,650
貴様ら、負の遺産という言葉を知らんのか。（ｗ

652 ：デフォルトの名無しさん：04/01/29 01:59

昔イジったシステムで、1つのカラムにカンマ区切りで値がはいってて、
それをsplitして他のテーブルを検索してくれってのがあったな。R-Oもクソもない。

Tierraって使ったことある人いない？
今仕様策定中のシステムで、TorqueかHibernateかその他のR-Oマッパーか
はてはJDBC+DbUtilsでゴリゴリか悩んでる中。DbUtilsでいい気がしてきた。

653 ：デフォルトの名無しさん：04/01/29 14:03

日本語の方が負の遺産だわな。
文字コードなんて複数あるんだし。

654 ：デフォルトの名無しさん：04/01/29 14:29

今イジってるPHP+MySQLのシステム、
１つのカラムに、PHPのオブジェクトをシリアライズしたやつが入ってるYO！
氏ね

655 ：デフォルトの名無しさん：04/01/29 15:14

>>652
そだね。
DbUtils程度で押さえておくのも一つの手かもね。

656 ：デフォルトの名無しさん：04/01/29 16:34

UTF-8がOSでもDBでもの文字コードの標準になればなんとかなるだろ。

657 ：デフォルトの名無しさん：04/01/29 17:03

>>656
Oracle使ってると、それでも問題は出る。
なにがへぼいって、varchar2をバイト数で指定するところ。
UTF-8だったら1文字当たり3バイトで計算とかだし。
ありえなくなーい？

658 ：デフォルトの名無しさん：04/01/29 17:41

>>657
だから、標準になったらだろ？

659 ：デフォルトの名無しさん：04/02/04 00:04

2chでマッピングツール作るってのはどうですか？

660 ：デフォルトの名無しさん：04/02/04 08:49

>>659
つくれるやつは、いろいろいるだろうが、
画期的な発想が思い付けないよね。
結局あれと同じジャンみたいな。

も前はどんなのが欲しいんだ。

661 ：659：04/02/04 11:28

>>660
例えばSQLを外部で管理( XML(SAP),DB等 )っていう方法
外部ファイルにオリジナルのSQL,INPUTパラメータ等を書く。
次にデータ設定用のクラスを作る。(String, int, Dateなどの動的配列(MAPとか) )

使用方法
１・外部データ作成時のSQL固有のキーを使用してオリジナルSQLを取得
２．INPUTパラメータがあればsetParam( ... ) で設定
３．SQLを完成させ、DBクラスに渡す。
４．DBクラスがDBのメタデータを元にデータ設定用のクラスの
　　適切な型にデータを設定
５．データ設定用クラスから列名で値を取得する。

肝はメタデータを使うってとこですね。
かなり思い付きです。
つっこみお願いします(w

662 ：デフォルトの名無しさん：04/02/04 11:42

>>661
複雑なSELECTの扱いや、
VIEWやSTOREDなどと、どう切り分けるかが鍵ではないでしょうか？
その辺りはどう考えています？

663 ：デフォルトの名無しさん：04/02/04 13:57

システムごとのマッピング程度なら、自分で書いてもそれほどじゃないんだよね。
如何に汎用にするかが問題になるわけで。

664 ：659：04/02/04 17:48

>>662
複雑なSQLとは具体的にどのようなものでしょうか？
VIEWはまだ考えていません(w

665 ：デフォルトの名無しさん：04/02/04 22:16

CASE WITHとか、FROM句にサブクエリ入れて条件絞ったりとか、
UNIONで完全外部結合やったりとか、OracleでSELECT ～ START WITHやったりとか？

666 ：659：04/02/05 00:53

>>665
それは大丈夫。
Statement$executeQuery後のResultSetを元に最終的に取得する列名などが分かるので。
あとHashtableを継承したクラスでgetメソッドをラップすれば使用する側でキャストする必要がなくなります。
(getString,getIntとか)
ストアドも同じ感じでいけそうです。

667 ：デフォルトの名無しさん：04/02/05 00:56

なんとなく汎用にすればするほどラップする意味なくなるくらい
外部ファイルに書く必要がでてきちゃって何したかったのかわからなくなる罠

668 ：デフォルトの名無しさん：04/02/05 09:41

そもそもそれって汎用マッピングツールを作るのは無理じゃないかと思うから、
そこらへんあきらめて、代わりにただのSQL文を簡単に使える仕組みを提供するとか、、？

669 ：デフォルトの名無しさん：04/02/05 09:51

>>661
それって、Sqletとあまりかわらないような。
http://homepage3.nifty.com/seasar/nazuna-sqlet.html
JavaBeansやMapへのマッピングまでやってくれるけど。

670 ：デフォルトの名無しさん：04/02/05 10:07

SQLの規格に従わない馬鹿をこらしめてやりたい。
諸悪の根源はベンダそのもの。準拠しないC++コンパイラが
ろくでなし扱いされるのとは大違いだな。まったく。

671 ：659：04/02/05 11:40

>>669
既にそんなものが(w
…でこういうのって需要ないのでしょうか？
Sqletを使われた人います？

672 ：デフォルトの名無しさん：04/02/05 14:07

>>670
スレ違い気味だが、激同。
ベンダー拡張使うなとは言わんが、互換性は持たせとけよと思う。
でも、DB屋さんってそういうとこ全然無頓着なんだよね。
以前仕事した人と話したとき、「なんで？DB違うんだから、当たり前じゃん」ってな反応だった。
そいつらが変わらん限り、ベンダは囲い込みが出来るわけだし、状況も変わらんなと思った。

673 ：デフォルトの名無しさん：04/02/05 14:24

>>666
それはResultSet->Objectの話でしょ？
それ自体が問題になることはあまりないように思う。

そうではなくて、クエリの自動生成をどのように行うか
ということ>662は言いたかったのではないのかな？

実際そこがｷﾓになると思うんだけど．．．

674 ：659：04/02/05 17:41

>>673
まさにSqletのように外部ファイルに書くって方法です。
使う側では検索条件があればINPUTを設定するだけ。
でgetString("列名"),getDate("列名")てな感じで呼ぶ。
XMLじゃなくてプロパティファイルにするなら
master.sql_1=select * from hoge where id ={0}
みたいにできるかなと。

…こういうのは使えないですか？(w

675 ：673：04/02/05 18:27

>>674
人によっては使うんでないかと思うよ。たぶん。
誰もが1度は考える方法だと思うし。

個人的に欲しいものは、
1.クエリがDBセーフで記述できる。
2.クエリを記述せずに、ある程度複雑なクエリを発行できる。
かな。

ちなみにTorqueは使いづらいと思っているけどね。

676 ：デフォルトの名無しさん：04/02/05 19:58

マップすると表形式でぐるぐる回して表示したい時に、逆に面倒なんだよね。
マップしないと、それ以外のすべてが面倒。

677 ：659：04/02/06 01:48

>>675
> 1.クエリがDBセーフで記述できる。
これはTorqueがやってますね。(未実装が多いけどw)
個人的にはSQLは自分で書きたいほうなので今のまま作ってみます。
あとTorqueみたいにたくさんのクラスを自動生成ってのは嫌ですね…。

>>676
MAPを継承したクラスを使えばいろいろできそうですが…。

678 ：デフォルトの名無しさん：04/02/06 11:20

出来る出来ないじゃなく、RSより面倒か面倒でないかの話だろ？

679 ：デフォルトの名無しさん：04/02/08 13:28

>>675
個人的にはある程度複雑なクエリを書く必要が出てくるんなら
素直にSQL書いたほうが早いと思うんだよね。

少なくともSQLは良く出来た言語だし、RDBのデータをOOAして
作ってきた側からから扱おうと思っても見過ごせないくらいの
ギャップが表面化するだけじゃないかと。

680 ：デフォルトの名無しさん：04/02/08 13:29

Commons DbUtilsってSqletと似たようなもん？

681 ：デフォルトの名無しさん：04/02/08 13:49

>>680
プログラマにSQLは書いてもらうけど、
底辺のJDBC APIはフレームワークが処理するという
意味では同じだね。

SOA(SQL Oriented Approach)

682 ：デフォルトの名無しさん：04/02/08 14:40

つーか、SQLが統一されれば問題ないんだろ？
Oracle8が無くなるまでの辛抱だ。

683 ：デフォルトの名無しさん：04/02/08 16:00

オブジェクト→いきなりただのテキスト→SQL→RDB→実行してみないと
結果わからん→JavaのデバグかSQLのデバグかわからん→1にもどる

コンマやスペースの所為で実行時エラーになるのは正直ウザい。
エラーになりゃまだいいけど、一生エラーにならんかもしれん。
でも、現状のO-Rマッパは、マッピングの設定がもっとウザい。

ってことで、俺はDbUtils。カユいところに手が届いてて良い感じ。

684 ：デフォルトの名無しさん：04/02/11 17:23

DbUtils 簡単そうで激しく気に入った。SQL 読み込みローダも付いてんだね。
ところで DB から Bean を作成する簡単ツールとか付いてこないんすかね？

685 ：デフォルトの名無しさん：04/02/11 23:39

俺もDbUtilsがいいと思う。
SQL書かないとね。

686 ：684：04/02/12 00:01

>>685
禿げ同。やっぱりほとんど制約なしでそのまま SQL で書けるのは良い。

>>684 読み込みローダ
。。。今見たら俺、馬鹿っぽさ爆発じゃないか。

687 ：デフォルトの名無しさん：04/02/12 01:52

>684
>DB から Bean を作成する簡単ツール

禿げしく欲しいが、多種多様のDBに対応させるために膨大なツールになって、
（DBのマイナーバージョンまで対応せんと、型のマッピング変わってたりするし）
「あんまつかえねえなぁ～」とかなりそう。結局、ExcelマクロとかPerlスクリプトとかで
ゴリゴリ作ってるほうが案外幸せなのかも。ある意味マッピングフレームワーク。

688 ：683 & 687：04/02/12 01:55

あ、いや、Torqueとか市販のO-Rマッパーの存在を否定してるわけじゃないのよ。
いろいろ試してみて、現状ではそう判断した。設定が簡単で軽いフレームワークが
あれば、今にでも飛びつきたいところなんだが。

689 ：デフォルトの名無しさん：04/02/12 23:39

DBUtils + (Generics + 可変長引数) = (ﾟдﾟ)ｳﾏｰ

690 ：デフォルトの名無しさん：04/02/13 00:56

うちの開発部ではExcelのマクロ使って仕様書から生成してら。

691 ：デフォルトの名無しさん：04/02/13 09:39

>689
仕事で使えるのはいつになるのやら。

692 ：デフォルトの名無しさん：04/02/13 15:18

8月アップの案件でDbUtilsは採用決定。1.5はどうかなぁ…。

693 ：デフォルトの名無しさん：04/02/13 16:24

DbUtilsは普通に採用するが、1.5はなー
特別な事情がなければ今年中は無いんじゃないかなー　そうでもない？
新しい仕様はみな微妙なものばかりだし、
すぐ使いたがるやつvs覚える気無いやつで内戦が起こりかねないし
コーディングルールだって直さないといけないからな・・・

694 ：デフォルトの名無しさん：04/02/13 23:00

間違ってたらごめんだが1.5ってまだreleaseしてないでしょ？
そんなもの仕事で使うの？
それはさすがにうちの会社ではありえん。

695 ：デフォルトの名無しさん：04/02/13 23:10

普通に考えたら新しい（beta含む）技術なんかリスクありありで
仕事で使わんな。でも新しい技術使いまくってアピールに
成功してる会社はあるな。ごく少数だけど。そっちのほうが
面白そうだ。

696 ：デフォルトの名無しさん：04/02/14 09:53

確かに面白そうではあるがリスクを誰が負うかが問題だな。
会社の方針としてあるのであれば使えるんだがね。

697 ：デフォルトの名無しさん：04/02/14 23:51

>>696
そのリスクを評価するのがエンジニアの仕事でしょうが

698 ：デフォルトの名無しさん：04/02/15 00:08

>>697 が責任を負います。

699 ：デフォルトの名無しさん：04/02/15 01:24

>>697
評価してるうちに正式版が出るわな

700 ：デフォルトの名無しさん：04/02/15 02:36

自分で一から書いたってリスクはあるんだから、
あり物使っても一緒だと思うよ。
金あるなら、MSとかOracleとかに囲われて
楽々やるのもいいかも知れないけど。

701 ：デフォルトの名無しさん：04/02/15 12:58

>>699
J2SE1.5 をいつもで評価する気？
えらくのんびりしたプロジェクトだな。

702 ：デフォルトの名無しさん：04/02/15 13:35

他人のリスクを自分で負うのと
自分のリスクを自分で負うのは
違う

たとえ他人のもののほうが自分のものより品質が良くても

703 ：デフォルトの名無しさん：04/02/15 15:15

あり物レベルのものが予算内で作れるなら、
自分で創って自分で責任負えばいいじゃん。
それが出来ないから、人を削って製品を買うか、
不具合覚悟であり物検証して使うかしてるんだって。

704 ：692：04/02/15 23:58

あぁ、すまん。1.5どうすっぺの言い出しっぺです。試作版が8月アップで、
正式版が来年春予定なのよ。んなもんで、DbUtils+1.5の組み合わせも一考の余地ありかと。
一考したけど、やっぱBeanListHandlerでゴリゴリやります。

705 ：デフォルトの名無しさん：04/02/17 00:12

DbUtil+DBCPってDbUtil継承して書き換えないと使えないですか？
DbUtilもデータソース使ってるみたいで…。
連携がちょっと厄介かも(w

706 ：デフォルトの名無しさん：04/02/17 08:10

>>705
おまえの頭を最初に書き換える必要があります。
継承して何を書き換えるつもりなんだ?

707 ：デフォルトの名無しさん：04/02/18 00:25

Torqueで、

select distinct HOGE from HAGE;

はどう書くんでしょう?

criteria.setDistinct();

のあるなし以前に、

Criteria criteria = new Criteria();
criteria.addSelectColumn(HagePeer.HOGE);
HagePeer.doSelect(criteria);

が、

com.workingdogs.village.DataSetException: Only 1 columns exist!

で落ちてしまい、困っています。

708 ：デフォルトの名無しさん：04/02/18 08:32

>>707
SQLと同等なことをするのに四苦八苦するような
フレームワークで時間をつぶすのはもったいないよ。

709 ：707：04/02/18 13:12

Criteria criteria = new Criteria();
criteria.addSelectColumn(HagePeer.HOGE);
Criteria criteria = new Criteria();
List list = BasePeer.doSelect(crit);
for (Iterator it = list.iterator(); it.hasNext(); ) {
Record rec = (Record)it.next();
System.out.println(rec.getValue(1).asString() );
}

でうまくいきました。

710 ：デフォルトの名無しさん：04/02/20 11:17

こういう問題があるから速攻止めたんだよな＞トルク
そーいやカウントの仕方がいまだわからないやｗ

711 ：デフォルトの名無しさん：04/02/20 20:31

JULP
ttp://julp.sourceforge.net/index.html
こんなんどう？

あと、
ttp://homepage2.nifty.com/igat/igapyon/diary/2004/ig040121.html
いが○ょんもなんかやってる。

712 ：デフォルトの名無しさん：04/02/20 22:11

>>711
> いが○ょんもなんかやってる

仕様案見たけど、これって車輪の再発明じゃないの？
そこのレスにあるけど、同じようなもの作ってる人いるし。

DbUtilsは低機能でORマッパーとは言わないかも
しれないけどシンプルで他と違って光ってるな。
漏れも同じ車輪しか作れないけど、誰かドカンと衝撃があるものを
世に出してください。

713 ：デフォルトの名無しさん：04/02/20 23:45

特別なマップ記述なしに、SQL発行してBeanのListで返ってくるというDbUtilsは、
JDBCと平のSQLを使ったJava<->RDB間車輪として完成したと言っても過言ではないと思う。
SQLになった時点でJavaと接点が切れるという問題はあるにせよ、相当使い易いもの。

後は、手を動かしてフレームワーク作るより、頭動かして発明するしかねえなぁ。

714 ：デフォルトの名無しさん：04/02/21 17:43

最終的には、Cayenne + Tapestryで決まりだと個人的に思う今日この頃。

715 ：デフォルトの名無しさん：04/02/21 19:42

マッピングツールで、Rogue Wave の SourcePro DB ライクなものってありますか？

716 ：デフォルトの名無しさん：04/02/21 23:32

>>714
Cayenne って他と比べてズバ抜けてるの？
それとも単に今までのORマッパの良いとこどり？

717 ：デフォルトの名無しさん：04/02/22 01:01

cayenneって、たしかXMLとかでスキーマをこさえてやらんでも
勝手にスキーマ構造を抜いてきてくれるんじゃなかったっけか。
WebObjectsのEnterpriseObjectFrameworkみたいな感じ？

718 ：デフォルトの名無しさん：04/02/22 01:23

torqueでもRDBからSchema抜き出す機能なかったっけ？

719 ：デフォルトの名無しさん：04/02/22 01:29

Torqueは、XML書かないとならないのでは？その必要も無し？
１テーブルあたり４クラスもできあがるのは、ちょっといただけないのだが。

720 ：デフォルトの名無しさん：04/02/22 01:36

Javaじゃないけど、金曜日のYukonセミナーで、
.NET版O-Rマッパーフレームワークみたいのを提供すると言っておった。
やっぱりデータ中心アプリだとO-Rマッパーが必要になってくるよね。
ということかな。

721 ：デフォルトの名無しさん：04/02/22 08:22

Hibernateは楽だぞ

722 ：デフォルトの名無しさん：04/02/22 09:51

Hibernateの楽なところって、具体的にどのへん？
スキーマのリバースとかできるの？

723 ：デフォルトの名無しさん：04/02/22 13:15

Middlegen で主要なORマッパーのスキーマのリバースは
出来るんじゃないの？ところで Middlegen で DbUtils 用の
Bean 作ったりはでけへんのかな？

724 ：デフォルトの名無しさん：04/02/22 13:41

>>719
torqueだがbuild-torque.xmlにjdbcターゲットがある。
これ使えば既存のDBからschema.xmlを生成してくれる。

725 ：デフォルトの名無しさん：04/02/22 13:51

>> 722
HibernateはMiddlegen + Middlegen-Hibernate(Hivernateのサイトから)で
スキーマのリバースが可能。

726 ：デフォルトの名無しさん：04/02/22 14:48

>>722
Eclipseプラグインのjfacedbc使ってもいけそうですね。

727 ：デフォルトの名無しさん：04/02/23 22:00

>723
Middlegenの素のままでは融通が利かないかもだけれども、
仕組みは結構単純なんで、自分プラグイン＋Velocityで
結構なところまでいけるのでは？

728 ：デフォルトの名無しさん：04/02/23 22:03

【ゴールデンレス】
このレスを見た人はコピペでもいいので
10分以内に3つのスレへ貼り付けてください。
そうすれば１４日後好きな人から告白されるわ宝くじは当たるわ
出世しまくるわ体の悪い所全部治るわでえらい事です

729 ：デフォルトの名無しさん：04/02/25 21:10

なーおまいら JTA って使ってますか？ ORマッパーと組み合わせて使うと
トランザクション管理が楽そうだけど、ググっても情報少ない。

Tyrex は更新止まってるし、JOMT はどうなんだろ。
ORマッパーに付いてるものとかないんかな？

730 ：デフォルトの名無しさん：04/02/25 21:48

>>729

素でSQL叩いたほうが楽ってことに気づいたんだよ

731 ：デフォルトの名無しさん：04/02/25 21:52

JTAなんざEJBコンテナに任しときゃいいんだ

732 ：デフォルトの名無しさん：04/02/25 22:01

>>730
いや、だから SQL は素でたたいてトランザクション管理だけは
JTA に任せようかと。。。まー落ち目ってことなんですね。。。

733 ：デフォルトの名無しさん：04/02/25 22:08

>>732
分散トランザクションの方が主な仕事じゃないの？
ローカルトランザクションは普通にJDBCのConnection#commitでしょ。

XA対応とか調べるのメンドクサイけどな。

734 ：デフォルトの名無しさん：04/02/25 22:26

>>733
EJB みたいに別コンテナまでのトランザクションはいらんけど、
Connection だと複数のクラスにまたがるトランザクションだと
いちいちコネクション渡していくのがめんどくさいなーと。

JTA だったらスレッド内だったら Connection 渡さなくても良いから
楽かな～と。俺、なんか間違ってる？

735 ：デフォルトの名無しさん：04/02/25 22:49

ここで相談していることがな。

736 ：デフォルトの名無しさん：04/02/25 22:50

>>734
なら、ThreadLocalでConnection渡したらどう？

737 ：デフォルトの名無しさん：04/02/25 23:10

>>736
うぉぉ。ありがﾄﾝ。ThreadLocal って名前しか知らんかった。
トリッキーそうだと思って Jacadoc 見たら、用途にトランザクションID とかって
ありました。これって EJB とかが内部で使ってんのかな？

738 ：デフォルトの名無しさん：04/02/25 23:40

JTAは普通ThreadLocal使って実装。

739 ：デフォルトの名無しさん：04/02/26 01:13

>>713
+BeanUtilsで、SwingともJSPとも相性いいな、それ。

すごい立派なシステム作るわけじゃなければ、それで平のSQL投げるのが
いちばん簡単なのかもね。
結局RDBMS固有のチューニングテクニックとかのお世話になる羽目になった
とき、平でSQL投げているほうが分かりやすいだろうし。
変な仕組みにSQL生成を任せてしまうと、わけわからなくなって困らへん
かな？

SQLを外部ファイルに切り出して、必要に応じてIDかなにかで呼び出す程度
がええのかな。

740 ：デフォルトの名無しさん：04/02/26 04:32

>>729
Hibernate + Spring Framework でこんなに簡単にできるよ
http://hibernate.bluemars.net/110.html

741 ：デフォルトの名無しさん：04/02/26 07:31

>>740
こっちも
http://www.springframework.org/docs/wiki/Spring_AOP_with_Hibernate.html

742 ：デフォルトの名無しさん：04/02/26 08:59

>>740
簡単じゃないができてるね。
読むだけで疲れたけど。
Springってすげって思うけど、なんかおやじが説教してるみたいな
感覚するんだよね。
うるせーって感じ。

743 ：デフォルトの名無しさん：04/02/26 13:34

>>742
この仕事に向いてない人だな。
自由にやられると、周りが困る。

744 ：初期不良：04/02/26 14:15

と言うか O-R マッピングって DB の種類に
依存しないためでもあるんじゃないの？
SQL たたく方が楽ってそりゃそうだけど
じゃあなんで苦労してコストもかけて
こんな事やっているのかと小一時間

745 ：デフォルトの名無しさん：04/02/26 20:42

>>744
本来そうかもしれんけど、俺は DB 置き換えが必要になった
PJ はあったことがない。あー ORマッパー使ってりゃ楽っだったのに！
とか普通はない。あんた、どう？

746 ：デフォルトの名無しさん：04/02/26 22:43

「思想的にしたくないことをやらなくてすむ」ってとこに意義があるんじゃないの。
まともなODB出たら、JavaでRDBとO-Rマッパなんか使う人はいないわけで。

747 ：デフォルトの名無しさん：04/02/26 23:47

>>746
>「思想的にしたくないことをやらなくてすむ」ってとこに意義があるんじゃないの。
結論はこれだと思う。

やっぱりオブジェクト指向な環境では、なるべくSQLなんつー対極的なものは使いたくないな。
ロジック中にSQL埋め込みたくないし（SQLも手続き的ロジックなわけだけど）、かといってSQLを
外出しにしたくもない。
オブジェクトの曼荼羅の中にSQL入れるなんて、清濁併せ呑むって感じがする。
ましてや、WebアプリなんかでPHPの中に、HTMLと一緒にPHPのロジックとSQLを混在させるような
腐った設計なんてのは問題外じゃねーの。

以上、個人的好みが多めだけど、客観的なOOP論は少なめ。これ。
オブジェクト指向は万能ではないってところも押さえないと。ね。

とりあえず、Hibernate / Cayenneﾏﾝｾｰ
Torque / JDOはｳﾝｺ。

748 ：初期不良：04/02/27 00:12

>>745
確かに DB 置き換えと言う事はあまり無い。
ローカルのテスト環境で別 DB を入れてテストするくらいかな。
けど、プロジェクト単位で DB 入れ替えとか言う話じゃなくて
こっちが複数の DB の独自仕様を意識しなくていい
と言うところじゃない？

思想的に、っていう話もわからないでもないけど、
漏れの場合は必要性如何に関わらず、抽象化を
進めた先に何かがあると信じてついて行く所存なり。
データをグラフ化したら違う何かが見えてきたってな感じのね。

749 ：デフォルトの名無しさん：04/02/27 00:17

これからは、１つのオブジェクトに、物理的に異なる鯖に配置されてる
アーキティクチャのことなるRDBのテーブルをマッピングして使う、
なんていうことが当たり前にできるようになりそうだね。
WebObjectsのEOFなんかが、かなり前から実現していた世界だけれど。
それがLGPLやASLなんかの製品でできるようになることの
ビジネス的なインパクトってどのくらいあるかな。

750 ：デフォルトの名無しさん：04/02/27 00:20

>>749
EJB

751 ：デフォルトの名無しさん：04/02/27 00:23

>>747
> とりあえず、Hibernate / Cayenneﾏﾝｾｰ
> Torque / JDOはｳﾝｺ。

おい、ﾏﾝｾｰの理由を教えてください。

752 ：デフォルトの名無しさん：04/02/27 00:28

>>751
個人的好みです。
使いたいものをプロジェクトの性格に併せて選択すればいいです。
JDBC+生SQLという選択肢も当然アリかと。

753 ：デフォルトの名無しさん：04/02/27 00:29

>>750
大規模案件には当然EJBっていう選択もありですな。
でも、中小規模案件にEJB(J2EE)適用すると、逆に工数増えるケースが多い罠

754 ：デフォルトの名無しさん：04/02/27 00:30

誰か OR マッパー比較表を作れるネ申はいませんか？
英語が不自由な漏れはﾀﾞﾒﾎﾟ。

例えばこんなん。（２ちゃんねるブラウザの比較表）
ttp://www.geocities.co.jp/SiliconValley-Sunnyvale/7562/

755 ：デフォルトの名無しさん：04/02/27 00:33

>>754
藻前さんの欲しいネタは、コレかい？
http://c2.com/cgi-bin/wiki?ObjectRelationalToolComparison

756 ：デフォルトの名無しさん：04/02/27 00:39

>>755
おわ！ありがﾄﾝ。
。。。なんか表がずれてる。漏れだけ？

757 ：デフォルトの名無しさん：04/02/27 00:42

>>756
表がｽﾞﾚるやつぁ～漏れんとこに来い！
漏れもｽﾞﾚてるから心配するな♪

758 ：デフォルトの名無しさん：04/02/27 19:41

Hibernate使うとき、Eclipse用のjFaceDbcプラグイン使ったら、
自動でスキーマ抜いたソースと、マッピングファイル作ってくれるよ（感涙）
ついでに、Hibernate開発チームのSteve氏が、サンプルソース大盛りで
DAO実装周りの解説してくれてるページもあった。
ttp://forum.hibernate.org/viewtopic.php?t=925108

もうこれは人として号泣するしかない。

759 ：デフォルトの名無しさん：04/02/27 22:56

Hibernateで、session.clsoe()してもDB側のコネクションが残っているんだけど、いいの？
SessionFactoryを最後にclose()してやると、完全に切れるみたいだけど。
これをやっていいのかどうか、確信が持てない。

760 ：デフォルトの名無しさん：04/02/28 00:06

>>729
Tyrexは1.0.1が出てるよ。元の開発元は放置してるらしく別のとこがやってるみたい。
1.0の時は悲惨なバグがちらほらあったなぁ。endResource()あたりのリスト繋ぎ換えで
循環リスト作って無限ループとかｗ今は完全に捨てたんで状況は追ってない。

JOTMはもっと酷かった。コネクションプールの実装が腐ってて、切れても永遠に
持ちっぱなしで、さらには仕様レベルで設計間違ってるから直す気おきなかったよーな。。

現在はJBossをJTA/JTSサーバとして使う形で落ち着いてます。
EJB鯖としては使ってないけど、自作のCMT実装も作ってあったので。
設定もすごい簡単だし、Tomcat+JTA/JTSというつもりで使うのもいいかも。

>>733
それも重要な仕事だけど、実際はそれだけじゃなくて、トランザクション管理のコードを
プログラマの管理下から切り離して書けるメリットの方が大きいと思うよ。
>>734が書いてるような使い方も容易にできるしね。

>>738
既に正式な仕様で決まって、それなりな実装(JBoss)もあって、WebLogic/WebSphere
みたいな商用サーバにも移行できる状況なのに、なんでわざわざそんなことすんの？
フレームワーク(Strutsとか)使って必ず通るコードを規定できれば、EJB使わなくても
そこでJTA叩くコード書けば十分じゃない？

遅レス+長文すまん

761 ：738：04/02/28 00:27

あー失礼。
JTAは普通ThreadLocal使って実装"されてるんだよ"、と
すぐ前の人に教えてあげたつもりだった。

762 ：760：04/02/28 00:39

>>761
ｽﾏｿ。736に対する誤爆でつ。。

763 ：デフォルトの名無しさん：04/02/28 00:44

Hibernate は JTA がサポートされていて、直接 JTA を叩かないでも使用できる。
Spring には JTA 抽象化レイヤがある。

> フレームワーク(Strutsとか)使って必ず通るコードを規定できれば、EJB使わなくても
> そこでJTA叩くコード書けば十分じゃない？

禿げ同。本来トランザクション境界は狭いほうが良いが、EJB の宣言型トランザクション
なんかめんどくさすぎる。基本的に境界はフレームワークの最初と最後で良いと思う。

764 ：デフォルトの名無しさん：04/02/28 01:14

>>745
>本来そうかもしれんけど、俺は DB 置き換えが必要になった
>PJ はあったことがない。あー ORマッパー使ってりゃ楽っだったのに！
>とか普通はない。あんた、どう？

自分もDB置き換えはあまり経験無いなぁ。
とりあえず、フリーのDBで作って、規模が大きくなってきたら商用DBに移行というのはあるかもしれんが、
最初からOracle使ってる場合は、DB置き換えってありえなくない？
OracleからpostgreやmySQLってパターンあるのかな？

自分の担当してるプロジェクトでトルク使うっていう案があるんだが、DBはOracleで決定済み。
SQLに精通したメンバーも数人いるので、JDBC+PL/SQL使用に間しての技術的な障壁はない。
現在、いろいろと調査してる段階なんだが、少なくても今のところは導入メリットが見えない。

ところで、トルクでOracleのrownumとかpostgreのlimitのようなことは可能でしょうか？

765 ：デフォルトの名無しさん：04/02/28 03:18

>>764
Jakartaスレにあったと思うが...
Oracle使ってsql書ける要員がいて、ストアドが使えるのならば
それが一番じゃない？

766 ：デフォルトの名無しさん：04/02/28 10:38

>>764
DBAがいるんだったら、Torqueなんてのはおすすめできない。
もしやるんだったら、iBatisとかいいんじゃない？

767 ：デフォルトの名無しさん：04/02/28 12:43

>>766
iBatisを語ってくれ。
Springでもサポートされて注目株だよね。

768 ：デフォルトの名無しさん：04/02/28 16:33

iBATIS Database Layer って SQL を XML に定義するタイプなんだね。
トランザクションとかプールもサポートしてるみたい。

誰かがダイアリーに Database レイヤも MVC と見るべきで、Model がテーブル（ビュー含む）、
Controler が SQL、View が ResultSet のような結果だって書いてたね。
レイヤとして切り離した場合、やっぱり SQL でええやんって流れなんか？
ストアドを DB に置く、SQL を Database レイヤに置く、似たようなもんか。

769 ：デフォルトの名無しさん：04/02/28 17:21

Hibernate + JFaceDbcﾏﾝｾｰ！

770 ：デフォルトの名無しさん：04/02/28 17:46

RDBのマッピングについて調べ始めて、
へー、こんなスレあったんだー、と思って>>1まで戻って読み返す気になった。

って、
あと一ヶ月で、立てられてから、１年たつんだな、ここ・・・。

771 ：デフォルトの名無しさん：04/02/28 18:23

>>770
じゃ、読んだあと 1 年前から今までの ORM 動向を
客観的にまとめて書き込んでください。

772 ：デフォルトの名無しさん：04/02/28 18:33

とりあえず日本じゃトルクマンセー派が多いんだけど、
使ってみたらハイバネートがいいようだな。
遅延ロードとか関連づけとか、テーブル操作も
HQLとCriteriaの使い分けができるしな。
日本語情報が豊富ならカイエンもモデリングツールがついててよさげだけど、
ハイバネートのようなかゆいところに手が届くほどの機能ではなさげ。
シンプルさでは良いかも。
JDOとか、OJBは、マッピング作業自体の手間とか後のメンテ考えると、
かなり使い込んだハイスキルな人間でないと使いこなせない気がする。

って、漏れは>>770じゃないけど、そんなことを思ってみるテスト。

773 ：デフォルトの名無しさん：04/02/28 18:36

>>768
MVCって、どのレイヤー間接続においてもそういう見方にするんでわ。
Springを覚えてからそう考えるようになった。

774 ：デフォルトの名無しさん：04/02/28 19:12

Hibernate > Cayenne > DbUtils > OJB > Castor > Torque
総合的にこんな感じか？ DbUtils はとりあえず。。。

775 ：デフォルトの名無しさん：04/02/28 19:51

>>773
本来のMVCでは、言われるような不思議な区分けはしないと思いますが。
そんなつまらないことを考えるのならば、BCEで普通にロバストネス分析
していけばいいはずです。
（無知故にMVC Model2をMVCと称し、しかも拡大適用していたのならば
　話は分かりますのが）

776 ：デフォルトの名無しさん：04/02/28 20:31

DBUtilsでRDBのテーブルをそのままマッピング、
テーブルとBeanは１対１対応・・・。
処理は結合も含め、全てJavaでやる・・・。
→RDBとJavaはほとんど完全に分離。

↓パフォーマンス的に問題あり

DBUtilsでRDBのテーブルをそのままマッピング、
集計処理が必要な場合、複雑な連結が必要な場合はView使用、
Viewも含め、Beanとデータベースの実体は１対１対応・・・。
→システムの一部がDBに入るので、DBの入れ替えは難しくなる。

ってやったら、小さい会社の社内システムくらいなら、簡単でいいかなあ・・・
そんなに導入にリスクもなく、学習の手間もなく、
恩恵は十分に、ってことで。

777 ：デフォルトの名無しさん：04/02/28 20:52

市販のDBMSでは、システムが大きくなるほど拡張キット(w が必要になってくる。
DBMSを使い込んで、運命を共にしましょうってところが多いってこと。そんな所
では、DBMSの移行だけで大仕事になるやね。
そもそも限定された言語環境からだけしかDBMSにアクセスしないなど、統合システム
ではあり得ないし。そこに言語限定の O/R mappingをもってきてもねえ。(w
ストアドにしておけば、建前上はどこからでも使用できて便利だし。

http://pc2.2ch.net/test/read.cgi/tech/1019996589/751
＞俺もできればストアドプロシージャの方が設計としていいと考えている。
＞こんな感じ。
＞
＞　EJBのCMP/BMP
＞　　＜ DAOパターンのPOJOにまとめる
＞　　＜ストアドプロシージャ
＞
＞単一DBMSと単一アプリによるシステムならまだしも、
＞複数のシステムから同じDBMS(の同じDBスキーマ)を操作したりするなら
＞ストアドプロシージャのほうがいいね。
＞
＞ましてや EAI のために統合DBを作りましょうなんてレベルなら、
＞確実にストアドプロシージャにすべきだ。

政治的な話が絡んでこないような小さいシステムしか構築しなくていいのなら、
それこそ何でも使えばいいんじゃない？

778 ：デフォルトの名無しさん：04/02/28 23:09

>759
Connection Poolが有効になっていないか？

779 ：デフォルトの名無しさん：04/02/28 23:18

>>777
やっぱJavaストアドプロシージャだよね。

780 ：デフォルトの名無しさん：04/02/28 23:24

>>777
DBの移行はありえない前提で、
ビジネスロジックをできる限りDB(ストアド）に入れてしまえ、と言っている？

781 ：デフォルトの名無しさん：04/02/28 23:37

>>780
政治的な話が絡んでくるのだから、DBの移行は非常に難しいだろう。
無条件にストアドで実現するのは、バランス感覚を欠きオカシイすぎる。

782 ：デフォルトの名無しさん：04/02/29 00:03

>>777
で、ストアド使うとして Java プログラムからは何でアクセスしてますか？
JDBC 直接ですか？トランザクションはどうしてますか？

783 ：デフォルトの名無しさん：04/02/29 00:10

いたずらにストアドに詰め込みすぎるのは保守性が下がっていいことないと思う。

と思っていたんだけど、>>779が言っているjavaストアド。
ttp://otn.oracle.co.jp/tech/java/jsp/
正直に知らなかったよ・・・。

これだとDBにべったりで、javaシンタクスで直接テーブルの内容を操作するような、
通常とストアドとまったく同じものを作れる、って事になるのかな？

だとすると、じゃあ、こんどは、DBの移行を考えないなら、
そして、一つのRDBを複数のシステムで使う場合、
これでDBシステムにビジネスロジックを全部盛り込んでしまっては
いけない理由は何だろう、と思ったり。
ちゃんと調べてないのでぜんぜんjavaストアドってのを誤解しているかも知れないけど。
さて。

だいぶすれ違い気味だけど、言うだけ言ってみる。

784 ：デフォルトの名無しさん：04/02/29 00:21

>>783
今すでにある JDBC でアクセスしてるクラスをストアドとして
DB に突っ込むだけ。
ん？じゃ、ORマッパ使ったクラスをストアドとして DB に
突っ込めばいいのか？って出来るんかな。

785 ：デフォルトの名無しさん：04/02/29 00:25

情報処理は土建と一緒だから、言われたことをこなすのが一番儲かる。

786 ：デフォルトの名無しさん：04/02/29 00:25

Javaストアド使えるのはOracle、DB2、PointBase、Sybaseくらい？

787 ：デフォルトの名無しさん：04/02/29 01:08

OracleのJavaストアドは、こんな感じ。
（詳細は、各種資料をどうぞ）
public static String sal_grade (String empname) {
　　float current_sal;
　　#sql {select salary into :current_sal from emp where ename = :empname };
　　if (current_sal > 0 && current_sal < 50000) return “ MTS”;
　　if (current_sal >= 50000 && current_sal < 100000) return“ SMTS”;
　　return (“Salary out of Range”);
}

>>783
うまく言えないんだが。ストアドでロジックが書けると言っても、何となく
これ以上のビジネスロジックは含めないでおこうというのは、PL/SQLの頃
からあったわけで。で、Javaでロジックが書けると言っても、その範囲を
大幅に超えてしまうのは抵抗がある。この辺りがバランスというやつだが、
人により感覚が違うと思うので、そういう意見もあると思ってほしい。

788 ：デフォルトの名無しさん：04/02/29 01:39

>786 一応PostgreSQL 7.4以降も該当するかな
http://gborg.postgresql.org/project/pljava/genpage.php?userguide

789 ：デフォルトの名無しさん：04/02/29 02:51

>>775
「達人プログラマ」読みなさい。

790 ：デフォルトの名無しさん：04/02/29 11:14

多層化や各レイヤを MVC と見るとか、どんどん分化している。
で、それを鵜呑みにして、そのまんま自分の PJ に適用しようとする香具師は
どうかしている。

例えば数十万人日の PJ があったとしたら極端な話、100 階層、各 MVC でも
いいと思う。管理できればだけど。
逆に小さなプログラム（PJまでもいかない）、DB内容を 1 画面表示させるだけで完結
するようなものだったら Servlet に直接 JDBC 書いて JSP だけで十分。
Servlet だけ JSP だけでもいい。

791 ：デフォルトの名無しさん：04/02/29 13:52

>>776
DbUtilsのためにわざわざViewなんて作らなくてもいいのに

792 ：デフォルトの名無しさん：04/02/29 13:55

DBの置き換えってなんとなく（社内の）開発環境から
（顧客の）開発環境に移すときにおきそうな気が。

特にOracle8iから9iへとかさ、普通のOracleから9iRACとかさ。
異なるバージョンだけどおおよそ一緒だろって感じで使ってるの多いような。

プライムで仕事とってるSIerでも社内の開発環境にはなかなか
金かけたがらないからあちこちのプロジェクトで環境共有してそうなんだけど。

793 ：デフォルトの名無しさん：04/02/29 14:55

>>792
どういう意味？開発（&テスト）環境と本番環境で DB が異なるってことか？

794 ：デフォルトの名無しさん：04/02/29 15:03

>>791
じゃあどうしたらいいのでしょう？

795 ：デフォルトの名無しさん：04/02/29 23:29

開発用と本番用が違うってかなりつらいね。
というか危なすぎない？
うちでは、できるだけバージョンまであわせて用意するんだけど。

796 ：デフォルトの名無しさん：04/02/29 23:41

>>790
開発側の都合でしかない部分については、「開発にとって適当な粒度」
で分ければいいって話は、MVC云々以前の話やん。当たり前やん。

797 ：792：04/03/01 01:01

>>793 >>795
顧客の本番環境＆テスト環境は買ってもらえる（顧客のお金）。
でも開発は自社でやるから、社内環境は自社の金で
準備しなきゃいけない。

って状況だと、よほどお金のあるプロジェクトじゃないと
専用の環境が作れなくない？
3ヶ月で回るプロジェクトが何本もあるとどうしても環境を
いくつものプロジェクトで共有することになる。
当然複数バージョンを同居することも難しくなる。
（保守のために環境残す必要もあったりするし）

まあ、社内がPostgresSQLで本番がOracleなんて極端な
違いはないけど、Oracle8iでも細かいところが違うのなんて
よくあると思う。

>>792にも書いたようなRACみたいなH/W巻き込んだ環境は
社内では作れっこないので確実にこういう状態だな。

798 ：デフォルトの名無しさん：04/03/01 11:23

DBUTILSとVIEWっていうのは実行速度の問題？

799 ：デフォルトの名無しさん：04/03/01 20:58

>>797
まじで？俺も結構な数の PJ やってきたけど開発環境と本番環境の
DB のバージョンが違うってのは無かった。
ってか、ありえんと思ってた。

で、いざ本番で動かしたら動かん、手戻りってのはないの？

800 ：デフォルトの名無しさん：04/03/01 21:55

O/Rマッピング技術は、そうした環境の差異から生じる影響や問題を、
最小限にとどめてくれるっていう側面もあるんじゃないかな。
WebObjectsのEnterprise Object Frameworkとかは、そうした
ウリもしてたしな。
開発はデフォルトで入ってるOpenBaseでやって、そのままOracleに持って行くとかできるそうだし。

801 ：デフォルトの名無しさん：04/03/01 22:07

最小限にとどめるってのは分かる。でも保証がない。
手戻りによる人的被害、莫大な損失、信用問題が出ないとは言い切れないよね？

バージョンちがうから動かなかったら許してね、規模の PJ なら
なら問題ないと思う。

802 ：デフォルトの名無しさん：04/03/02 00:09

それ、なんでもそうだよな。
「これこれ、こうやると早いし簡単なんです。これでやりませんか。」
「それって、これこれこういうときって大丈夫？」
「うーんたぶんだいじょぶだと思いますけど？」
「確信できないなら、今回はちょっとやめといてもらえます？」
（うー。自分で責任持つともいえないから、じゃあ、やめとくか。たぶんだいじょぶだと思うんだけど・・・）
って感じ。

803 ：792：04/03/02 01:03

>>799
周辺ではバージョンの違いに起因するような細かな機能は使ってないから
助かってるんだろうね。
DBっていったって単にSELECT/INSERT/UPDATE/DELETEしてるだけ
なのが多いから。
当然手戻りのリスクはあるが、環境作るコストと比べたら小さいと踏んでるわけだ。

まあ、たまたま周りがそうだっただけかも知れんけどね。
会社移っていきなりこうだったのでカルチャーショックは受けた。

804 ：デフォルトの名無しさん：04/03/06 21:04

このスレ見てDbUtils使ってみようと思ったんだが、OracleだとINTが
BigDecimalになるんで値をセットしてくれない。
Oracle使いの人はどうしてんの？

805 ：デフォルトの名無しさん：04/03/06 22:53

Oracleは、Oracle社の各製品に囲われないと幸せになれないんです。

806 ：デフォルトの名無しさん：04/03/07 10:40

>>804
それだけじゃなくほかにも幾つか問題ある。
Oracleでテストするだろう普通 -> DbUtilsの開発者
今のところはソースに手を入れるしかないんじゃないかなぁ。
で、本家に報告汁。
漏れは、Oracleでテストしていない段階で使うのあきらめた。

807 ：デフォルトの名無しさん：04/03/07 12:51

>>804
そのために RowProcessor 実装できるようになってんじゃないの？
いや、使ってないんで知らんけど。

808 ：デフォルトの名無しさん：04/03/07 13:33

当てずっぽうだけど、DBUtilsのせいというよりは
OracleのJDBCドライバに原因があるんじゃないかな。
NUMBER型の列に対して
ResultSetMetaData#getColumnClassName(int)を呼び出すと
BigDecimalを返すようになっているとか。
DbUnit使ったときに同じような問題（SQL NUMBER型がBigIntegerで返ってくる）が出た。

今、手元にOracleが無いので試せませんが。

809 ：デフォルトの名無しさん：04/03/07 13:42

実際、Oracle使いはRowProcessor自前で実装してんのかね？
なんだか、単純に実装するとテーブル毎にRowProcessor書いて
しまいそうだし、そいつを共通化しようとするとBasicRowProcessorの
再実装になっちゃいそうな気がしたんだが。

BasicRowProcessorのいくつかのprivateメソッドがprotectedだったら
再利用してサブクラスで簡単な拡張するだけでいけそうなのに。

ColumnProcessorが導入される1.1に期待か。

810 ：デフォルトの名無しさん：04/03/07 14:18

DbUtilsは手軽さがウリなわけだから、Beans側のプロパティの
型がObjectだったら型チェックせずに無条件でセットして、あとは
自分でバンバンしてね、くらい割り切ってよかったと思うんだけどね。

811 ：デフォルトの名無しさん：04/03/07 15:13

Beanとテーブルを1対1で対応させる場合、テーブルの結合が必要なものはどうするのが良いですか？
Beanの作成方法と、DAOを使用した時のDAOクラスの実装方法（AとBを連結した場合、
どっちに実装するとか）について悩んでます。
>>776　のようにViewを作成する場合は数が多いと大変ですね。
IDでマスタから検索したNAMEをトランザクションテーブルにinsertとか結構あると
思いますが。

812 ：デフォルトの名無しさん：04/03/08 07:16

>>811
だまってHibernateつかえ

813 ：デフォルトの名無しさん：04/03/08 07:17

>>811
おいらはDAOにA.setB()とかB.setA()とか他の結合可能なDAOを設定できるメソッドを作って、
クエリ時にSELECT文とJOIN文を自動生成する実装を書いたことがある。
ただしカラム名の重複には注意すること。

814 ：デフォルトの名無しさん：04/03/08 09:58

Oracleは一部の仕様がクソ過ぎ。
number型の場合BigDecimalで返すのはすごい桁数の数字返す可能性があるからしょうがないとしても、
varchar2で4000って指定したら4000byteな上に、JDBCから書こうとすると1文字3byteで計算しやがるのはどういうことよ。
おまえら、ここら辺どうやって対応してるの？

815 ：デフォルトの名無しさん：04/03/08 10:10

>>814
3byteで計算して余分な空白埋めやがった上に、
それが原因で、カラムの最大長を超えるってどういうことやねん。
読み込んだのを書き戻せないジャン。

後続の空白は、トリムもしくは指定のbyteを超えた分を
切り捨ててます。

この辺はフレームワークで吸収して欲しい。

816 ：デフォルトの名無しさん：04/03/08 10:26

>>815
varchar2をStringで取り出すと空白は入らなかったような。
charだと空白入ってくるけど。

817 ：デフォルトの名無しさん：04/03/08 12:20

>>814
禿げ同。仕様と言い切る Oracle は糞。殿様商売で感覚が麻痺してるとしか思えん。
俺は 8i でそうだったけど、9i、10g でもその仕様のままなんだろうか？

818 ：デフォルトの名無しさん：04/03/08 13:30

>>817
10gはしらんが、9iでは変わってない。
ダメすぎ。

819 ：デフォルトの名無しさん：04/03/08 15:17

>>814
よう知らんのですが、SQLServerのvarchar(バイト単位で格納)に対する、
nvarchar(ユニコードで格納)みたいなのはないの？

820 ：デフォルトの名無しさん：04/03/09 11:11

CastorとHibernateを比べた人っていますか？
今度WEBサービス（SOAP・MESSAGE)でORマッピングやろうと思ってるんですよ。
Castorを使ってテストで買い物サイト作ったことがあって結構いいかな、って思ったんですけど
結構Hibernate良いって言っている人もいるっぽいので。
どうでしょうか？

821 ：デフォルトの名無しさん：04/03/09 11:13

Hibernateは、jFaceDbcプラグインと組み合わせると、
スキーマのリバース＆ソース自動生成ができるのが(･∀･)ｲｲ！

822 ：デフォルトの名無しさん：04/03/09 12:11

middlegenとcodeジェネレーターつかうのといっしょ？

823 ：デフォルトの名無しさん：04/03/09 12:23

middlegenの方がリレーション見てくれる分、一歩リード

824 ：デフォルトの名無しさん：04/03/09 13:31

middlegen使ってコード生成するのって、
XMLとか書かないとだめ？

825 ：デフォルトの名無しさん：04/03/09 14:25

middlegenのＤＢの設定とかは
ＸＭＬファイルでやるんじゃなかったっけ？
プロパティファイルだったか？

826 ：デフォルトの名無しさん：04/03/09 14:47

jFaceDBCは、DBに接続すれば、マッピングソースと設定ファイルを
イッパツ生成してくれんだね。

827 ：デフォルトの名無しさん：04/03/09 21:56

JFaceDbc ってリレーション見てくれないのか・・・

828 ：デフォルトの名無しさん：04/03/10 09:42

？外部キー見てくれないってこと？

829 ：デフォルトの名無しさん：04/03/10 12:29

>>828
そう。要は1テーブル分しか作れない。

830 ：デフォルトの名無しさん：04/03/11 22:18

>>809
BasicRowProcessorをコピペして、
ConvertBigDecimalRowProcessorとかいうのを作って対応しました。

将来的には、標準で対応されるだろうから、
それまでのつなぎと思って使います。

831 ：デフォルトの名無しさん：04/03/18 20:10

hibernateで・・・

832 ：デフォルトの名無しさん：04/03/18 20:11

hibernate使っている人います？

833 ：デフォルトの名無しさん：04/03/18 21:02

います。

834 ：デフォルトの名無しさん：04/03/18 23:12

>>820
HibernateもCastor JDOも両方使ったことあるけど、
Hibernateの方がO/Rマッピングの自由度が高いし、
クラス設計上の制約も少ないからやりやすいよ。

835 ：デフォルトの名無しさん：04/03/19 21:53

ORマッパー + IoCコンテナｻｲｷｮｰ
EJB のトランザクション制御ｲﾗﾈｰ

とりあえず Hibernate + SeasarV2 に期待。

836 ：デフォルトの名無しさん：04/03/19 22:36

もうすぐ春ですね...

837 ：デフォルトの名無しさん：04/03/19 22:39

>>836
コピペ厨Uzeeeeeeeeee!

838 ：デフォルトの名無しさん：04/03/19 23:13

>>835
その組み合わせで何がうれしいかというと
EJBっぽく宣言的トランザクションができることかと。

あと、EJBのトランザクションはRDBMSだけじゃないよ。

839 ：デフォルトの名無しさん：04/03/20 00:05

>>838
コード中でも宣言できるし、POJO で宣言トランザクションできるってのが
大きいと思う。DbUtils とかと組み合わせたりとか。

EJB のトランザクションって RDBMS 以外にどんなのが使われてるの？

840 ：デフォルトの名無しさん：04/03/20 10:47

>>839
JMS(WebSphere MQ)

841 ：デフォルトの名無しさん：04/03/20 13:24

ちょっと気取って見ませんか

842 ：デフォルトの名無しさん：04/03/20 14:02

恋をしてみませんか

843 ：デフォルトの名無しさん：04/03/20 16:08

Hibernateで、Ehcacheを使っています。
キャッシュのオブジェクト上限値（maxElementsInMemory）を設定して
いますが、上限値を超えてもキャッシュから取得できてしまいます。
overflowToDiskを"false"と設定した場合は、キャッシュから削除される
と思っているんですが、他に設定等あるのでしょうか？
よろしくお願いします。

844 ：デフォルトの名無しさん：04/03/20 20:12

Seasarってライセンスどうなってんの？
ライセンスが英語なんで分からんす・・・
ttp://seasar.sourceforge.jp/

845 ：デフォルトの名無しさん：04/03/21 19:31

>>844
ひとことでいえば、「好き勝手に使っていいぞゴルァ！」ってこと。

846 ：デフォルトの名無しさん：04/03/22 15:07

>>845
んなこたあない。

ASL 1.1ライクなライセンスになってるので
http://www.terra-intl.com/wiki/?Apache%2FSoftware%2FLicense
でも参考にしてくだしあ

宣伝条項も忘れずにね

847 ：デフォルトの名無しさん：04/03/29 12:04

hosh

848 ：デフォルトの名無しさん：04/03/30 08:35

http://pc5.2ch.net/test/read.cgi/tech/1068207164/l50
このスレの721です。Strutsを使われている人が居たら
アドバイスを頂けたらと思います。

私はHibernateを使っています。HSQLでテーブル名を全部大文字
にしたら怒られた（実行エラー）のって私だけでしょうか・・・。

849 ：デフォルトの名無しさん：04/03/31 02:41

>>848
とりあえず、質問の仕方の基本や、掲示板のマナーを理解してから出直してくれるか？

850 ：848：04/03/31 08:43

ごめん、全然マナーが悪い事してないと思っているんですが。
マルチポストだと思われてるんでしょうか。
流行の言葉で言えば、TrackBackみたいなものだと思っています。

是非理由を聞かせてください。

851 ：デフォルトの名無しさん：04/03/31 14:59

>>850
使ってるDBMSは書いていないわ、JDKやHibernateのバージョンは書いていないわ、
どういうコードでそうなったか説明していないわ、レス番号を指定しないでリンクを貼るわ…

一番の基本を言うと、それで動くかどうか、まず自分でやってみろよって話だよ。
あとは自分で作ったBeanの役割くらい性格に理解しろ。
フレームワークの情報交換やそういうレベルの話ではない。
ここはサポートじゃないんで、まず基本を理解しているのかも怪しいうえに
実際に試しても見ない奴に、誰も回答はやらないよ。

852 ：デフォルトの名無しさん：04/03/31 15:08

>>851
は・げ・ど・う

853 ：デフォルトの名無しさん：04/03/31 22:26

自助努力無しの他力本願厨か。典型的だな。
主張ばっかりで責任は果たさんと。

854 ：848：04/04/02 08:39

ごめん、ごめん
>私はHibernateを使っています。HSQLでテーブル名を全部大文字
>にしたら怒られた（実行エラー）のって私だけでしょうか・・・。
これは質問っていうか愚痴。Fromの後はテーブル名でなく、対応するうクラス名
なんだね。激しく勘違いしてました。

>レス番号を指定しないでリンクを貼るわ…
721って書いて在るじゃん・・・。

855 ：デフォルトの名無しさん：04/04/02 11:59

>>854
では、これからは
http://pc5.2ch.net/test/read.cgi/tech/1068207164/721
と書くようにしてください。

856 ：デフォルトの名無しさん：04/04/02 16:07

重要なのはこの辺だろ、ボケ

>一番の基本を言うと、それで動くかどうか、まず自分でやってみろよって話だよ。
>あとは自分で作ったBeanの役割くらい性格に理解しろ。
>フレームワークの情報交換やそういうレベルの話ではない。
>ここはサポートじゃないんで、まず基本を理解しているのかも怪しいうえに
>実際に試しても見ない奴に、誰も回答はやらないよ。

857 ：デフォルトの名無しさん：04/04/03 17:18

848ってそんなに激しく突っ込む書き込みか？

それより漏れは
848>>HSQLでテーブル名を全部大文字にしたら
851>JDKやHibernateのバージョンは書いていないわ
HSQLとSQLを勘違いしてるって何故に突っ込まない？
JDKのバージョン云々こっちの方が笑える。

俺的に重要なのは
>あとは自分で作ったBeanの役割くらい性格に理解しろ。
だけだな。実際やってみてるから、エラーでつまずいてんだろうが（ｱﾊ
DTOはそもそも冗長なもので、848はFormとテーブルがまったく同じに
なっちまったから、なおさらその冗長性を疑問に思ったんだろ。

そろそろ、スレの本題に戻ろうか。ってもネタが出尽くしてる
みたいだが。

858 ：デフォルトの名無しさん：04/04/03 22:11

Hibernateで、複合キーを使ったselect方法は、どんな感じ？

859 ：デフォルトの名無しさん：04/04/04 01:14

>>857
やってみてエラーになりましたなんて一切書いてないぞ。
同じようなクラスが出来るけど、共用できるんですか？だろ。
やって正常に動かないなら、質問するまでもない問題。

860 ：デフォルトの名無しさん：04/04/04 21:27

>>859
わかったから。もういいよ。

861 ：デフォルトの名無しさん：04/04/04 21:37

>>859
まー、お前が何人かをムカつかせたのは事実。
2chごときでのコミュニケーションスキルが足りないってこった。
もう書き込むな。素直にROMしてろ。

862 ：デフォルトの名無しさん：04/04/04 22:06

>>860-861
そんなに悔しかったのか？
指摘した奴がむかつかせたのは質問者だけ。
質問した奴がむかつかせたのは見ていた奴の殆ど。

863 ：857：04/04/04 23:34

>>859
>同じようなクラスが出来るけど、共用できるんですか？だろ。
Strutsスレの方よく読んだか？出来る出来ないの話じゃないだろ。
すべきか、すべきじゃないかの設計の話。それとも絶対に出来ない
とでも言いたいのか？
>やって正常に動かないなら、質問するまでもない問題。
動く動かないの話じゃない。
だから851の書き込みも
>あとは自分で作ったBeanの役割くらい性格に理解しろ。
って設計の指摘になるんだろう？

>>858
JDKのバージョン書かないと、変なのに絡まれるぞ（ﾜﾗ
ちなみにこんな感じか。
session.find("from Test where key1 = ?, key2 = ?",
　　　　　　new Object[]{"test", new Integer(1)},
　　　　　　new Type[]{Hibernate.STRING, Hibernate.INTEGER})
手元に動く環境が無いから間違ってたら、きもいやつか、まともな
人が突っ込んでくれるだろう。検索キーが多くなったらcreateSQLQuery
で使うと、いいかもしれん。

もう少しﾏﾀｰﾘやろうや。

864 ：デフォルトの名無しさん：04/04/04 23:51

>>863
> もう少しﾏﾀｰﾘやろうや。

とか言いながら、一言多いね↓

> 手元に動く環境が無いから間違ってたら、きもいやつか、まともな
> 人が突っ込んでくれるだろう。

865 ：デフォルトの名無しさん：04/04/04 23:56

>>863
複合キーセレクト、クスコ！
明日試してみるね！

866 ：デフォルトの名無しさん：04/04/05 00:16

>>863
各Beanがどうしてそういう構造になって、どういうデータが入って、
入ったものの状態がどうなって、それを踏まえたうえで
分けるべきかどうかの理解をしていないんだから、
分ける分けないの回答だけ教えても意味ないんじゃない？
親切な君が向こうのスレで、手取り足取り一から教えてあげれば？

867 ：デフォルトの名無しさん：04/04/05 01:32

荒れた原因はこの一言に尽きるな

>>850
>全然マナーが悪い事してないと思っているんですが。

868 ：デフォルトの名無しさん：04/04/05 03:33

>>863
>Strutsスレの方よく読んだか？出来る出来ないの話じゃないだろ。
>すべきか、すべきじゃないかの設計の話。それとも絶対に出来ない
>とでも言いたいのか？

読解が2者に分かれている時点で、質問が悪いんじゃないかと思う。

869 ：デフォルトの名無しさん：04/04/05 06:22

まぁ、どっちにしろ、2chの使い方が解らないんだったら、
偉そうにマナー違反ではないですなんて言わずに、もう半年ROMれってことだ。
TrackBackって言いたいだけちゃうんかと。
リンクだけ張っても、元スレが過去ログ行きになったら
なんの話だかも解らなくなるわけだし。

870 ：デフォルトの名無しさん：04/04/05 23:23

無意味な叩きレスに嫌悪感を示すレスがつくだけでも、
まだ、このスレはいいほうだってのが分かるな。

871 ：デフォルトの名無しさん：04/04/06 01:34

JOINするならHibernateタンで決まり、ということらしいですが
プロジェクトの都合でDAO自作の場合に設計とか
参考になる書籍・サイトはありますか？

Entityクラスのリレーションオブジェクトを取る時に
・Entity#selectRelation(key)みたいなのを定義すると
Entity is DAO になるんで悪い設計？
・フェッチするときにリレーションまでごっそり取得して
Entity has Relation(Collection)で持たせるのはあり？

とか悩みます。

872 ：デフォルトの名無しさん：04/04/06 10:25

>無意味な叩き

だれも質問の仕方の悪さや、掲示板の使い方を指摘しないと、
厨房的な振る舞いの奴ばっかりになって荒れるぞ。
誰かが悪役を買って(まぁ匿名だけど)注意してくれるから、
掲示板のルールというものが維持されていくのではないかと。

873 ：デフォルトの名無しさん：04/04/06 10:36

>>871
現時点で一番認められている Hibernate を参考にすれば？
書籍とかサイトでは Hibernate 以下しか望めない。

874 ：デフォルトの名無しさん：04/04/07 21:11

Seasar2がHibernateに対応したようだ

875 ：デフォルトの名無しさん：04/04/07 21:53

対応って、具体的にどのような方法で？

876 ：デフォルトの名無しさん：04/04/08 08:03

>>875
http://homepage3.nifty.com/seasar/s2hibernate.html

877 ：デフォルトの名無しさん：04/04/08 09:10

>>876
ｸｽｺ

878 ：デフォルトの名無しさん：04/04/11 19:27

JavaのORマッピング・フレームワークを7～8年前からやってる者です。

DAOのGeneric化は、現在のJavaではできない、という説がこのスレで囁かれているようですが、
そんな事はなく、Java 1.02レベルでも充分できるはずです。
以上、ご参考情報でした。

879 ：デフォルトの名無しさん：04/04/11 20:07

このスレなんとなく荒れてたみたいだけどｗ

ここで荒らしてる人物、俺が数年前に情死す板でORマッピングのレクチャーしてやった厨房のような気がする。
奴はルサンチマンの塊で、趣味はスレ潰しだから、放置しておくのが一番だよ。

880 ：デフォルトの名無しさん：04/04/11 20:26

君が言っている、潰そうとしている厨ってどっちの人？
アホな質問して逆切れするほう？それを注意するほう？

881 ：デフォルトの名無しさん：04/04/11 21:16

レクチャーだって・・・
なんか恥ずかしくなる･･･

882 ：デフォルトの名無しさん：04/04/11 21:39

こんちわー、報知新聞のほうから来ましたー。
巨人阪神戦のチケット、差し上げますー

883 ：デフォルトの名無しさん：04/04/11 23:17

>>882
品川駅の方面の業者さんですか。
わざわざご苦労様です。

884 ：デフォルトの名無しさん：04/04/12 15:42

Hibernateでストアドプロシージャー呼びたいときって、
SessionFactoryからsessionもらって、そこから connection()メソッドで
JDBCコネクション(java.sql.Connection)を得て、
あとはCallableStatement使ってSP呼んでやればいいのかと思ったんだけど、
SPが実行されないような感じ。
だれか成功してる人いる？

ふつうに、DriverManager#getConnection()使うと、問題なくSP呼べるんだけど。

885 ：884：04/04/12 16:26

解決しますた。
使ってるRDBMSが、IBMのDB2 v8.1?だったんだけど、
スキーマ名を指定してやらんといけない場合に、SP呼ぶときだけ
スキーマ名がCase Sensitiveだった。。。
イメージとしては、

session = factory.openSession()
connection = session.connection()
CallableStatement stmt = connection.prepareCall("CALL SCHEMA-NAME.sp(?)")
stmt.execute()

ってな感じだった。
吊ってくる。。。

886 ：デフォルトの名無しさん：04/04/12 21:19

>>878
レクチャーしてくれ。

887 ：デフォルトの名無しさん：04/04/14 13:27

>>878-879
Gimme a lecture!

888 ：デフォルトの名無しさん：04/04/20 11:07

Hibernateで、hibernate.cfg.xmlでconnection.pool_sizeを指定できるわけだけど、
ここで設定したコネクションプールをきちんと使えているかどうかの確認って、
どうやったらいい？
SessionFactoryからsessionを取得した複数オブジェクトに対して、
System.identityHashCode()
を用いて確認を試みると、１カ所のメモリしか使ってないような印象を受ける。

889 ：888：04/04/20 14:46

自己解決しますた。
hibernate.cfg.xmlに、プーラーの設定せんといかんかった。。。

<property name="c3p0.min_size">1</property>
<property name="c3p0.max_size">3</property>
<property name="c3p0.max_statements">10</property>
<property name="c3p0.timeout">100</property>
<property name="c3p0.validate">true</property>
<property name="hibernate.connection.provider_class">net.sf.hibernate.connection.C3P0ConnectionProvider</property>

こんなかんじ。
max_size超えた接続時には、ちゃんと待ちになってくれるようになった。

最初は、プーリング設定は
<property name="hibernate.connection.pool_size">3</property>
これしか書いてなかった。。。
これって、built-in poolingってやつかな？
プーラーはc3p0使った。Hibernateにも同梱されてる。
(ttp://sourceforge.net/projects/c3p0)

890 ：デフォルトの名無しさん：04/04/21 09:29

チュートリアルとかに出てる、ThreadLocalを使った
HibernateUtilなんていうクラスでｾｯｼｮﾝを取得する場合、
コネクション・プーリングは有効なんかね？

891 ：デフォルトの名無しさん：04/04/24 21:01

Cayenne In Action ﾏﾀﾞｰｰ!?(AA略

892 ：デフォルトの名無しさん：04/04/27 23:52

DBUtilsって結果がリストで返ってくる、ってことはメモリ上に乗っかるんだよね？
数万件オーダーの結果が返ってくるようなWebアプリで使うのは、やっぱり避け
るべき？

これが心配でTorqueも回避したんだけれども。

893 ：デフォルトの名無しさん：04/04/28 00:18

ああ、それは俺も気になってる。
BeanutilsのDynaBeanとか。

894 ：デフォルトの名無しさん：04/04/28 00:19

RowSetDynaClassの間違い。

895 ：デフォルトの名無しさん：04/04/28 00:27

>>890
HibernateUtilで実装されているセッション取得方法だと、
コネクションプールは使わないだろ。
SessionFactoryから、openSessionだかなんだかしてやるべし。
（SessionFactoryは、１つのRDBに対しては必ず１つであるべきらしい）
んで、設定ファイルにもちゃんとプーリング設定すること。
ConnectionProviderを設定しないとプールは使われない。

896 ：デフォルトの名無しさん：04/04/28 00:37

>>892
よくはしらんが、逐次streaming処理っぽいことをやるんなら
ResultSetIteratorをつかうか、独自にResultSetHandlerを定義すれば
よさげ。ただ、もともと薄いDbUtilのラップがさらに薄い感じになるんで
あまり旨味はないかも。

897 ：デフォルトの名無しさん：04/04/28 00:43

>>892
Hibernate使えば？１回の取得件数とか指定できるよ。
ページング処理みたいな感じで。

898 ：デフォルトの名無しさん：04/04/28 06:55

ＲＤＢの人の会話って、
だから何？
つうくらい薄っぺらくてやんなる。
フレームワークやクラスのデザインするわけでもなく、
「ただ～というフレームワークでは～という機構を使ってるから、順当な設計では～は無理」
って、アタマ悪そうな会話だよな。
理想のＳＱＬなりＲＤＢなりを忠実にモデリングした言語使いたいなら、
ＰＬ／ＳＱＬでも使ってろって感じ。

でも、そーゆー普通の人々でも仕事こなせるような環境が、工学的には良い環境、
なのだという事実に思いを巡らせると、うーん、（自粛

899 ：デフォルトの名無しさん：04/04/28 11:34

>>897
あれこれ言いたい気持ちは理解できる。
でも、便利なモノがあって、アーキティクチャまで理解せずとも
効率と品質がある程度確保できることがそれなりに把握できていれば、
それを選択することは間違っていない。

世の中は、「道具を作る人」と「その道具を使う人」がいる。
全員が作る人になったら意味ないだろ。

それに、ここは、Java<->RDBのマッピングフレームワークを語るスレだ。
おまいさんが語りたい内容とはｽﾚ違いだと思われ。
RDB自体か、ﾌﾚｰﾑﾜｰｸやｸﾗｽをﾃﾞｻﾞｲﾝすることを語るｽﾚに逝け。

900 ：デフォルトの名無しさん：04/04/28 12:30

>>898
だから何？

901 ：デフォルトの名無しさん：04/04/28 18:06

>>898
これだから、理論屋は使い物にn(ry

902 ：デフォルトの名無しさん：04/04/28 22:05

WebLogicはどのマッピングツールをサポートしてるの？

903 ：デフォルトの名無しさん：04/04/29 09:41

こいつは理論屋にもなれない知ったか厨だろ？

904 ：デフォルトの名無しさん：04/04/29 14:57

つまりPL/SQLって言いたかっただけと。

905 ：デフォルトの名無しさん：04/04/29 19:52

はい、よい子のみんな、O/R-Mappingを語ることに戻るよ～

906 ：デフォルトの名無しさん：04/04/29 23:59

DbUtilで十分

907 ：デフォルトの名無しさん：04/04/30 01:39

>>899-906
おまいさんら、ORマッピングの目的って、何だと考えてるの？
問いかけのない無目的な行為は、地獄への直通列車だよん。

908 ：RDB素人 (永遠に素人のまま済ませたいものだ)：04/04/30 01:45

ところで、最近 Result Cache って普及してるの？

ResultCacheっておおまかに言って、
同じqueryで検索対象が更新されていなければ、キャッシュした検索結果を返す機構で、
KIVA AS～Netscape AS～iPlanet iASの系譜でJavaによる初期の実装が行われてたらすぃ。(@ITに関連記事あり)
2000年頃には、既にResult Cacheという単語がGoogle上からすら消えていて、
Oracle8iかなんかが似たような機構を次期リリースで提供、とかいう話は確認したのだけれど。

なんでこんな古い話題を振るかというと、KIVAのメンテ＆アプリサーバ変更の話が（ｒｙ
日本ネットスケープの残党はどこに（ｒｙ

909 ：908：04/04/30 01:48

そー言えば、２０世紀末期には、ASといえばKIVAの時代があったなあ～。
AS～KIVAの情報収集で、ちゃっかり海外出張した上司は、今ナニをやってるのやら

910 ：デフォルトの名無しさん：04/04/30 04:25

KIVAってなに？

911 ：デフォルトの名無しさん：04/04/30 08:59

>>910
ttp://www.google.com/search?num=50&hl=ja&ie=UTF-8&oe=UTF-8&q=KIVA+%2B%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%B5%E3%83%BC%E3%83%90&lr=lang_ja

912 ：デフォルトの名無しさん：04/04/30 09:04

そういやCayenneって、スキーマ情報ぶっこぬきツールが付いてるのな。
まだ試してもいないけど、リレーション情報まで抜いてくれるのかな。
WOのEOModelerを参考にしてるようだからやってくれそうだけれど。。

HibernateのFAQでなぜGUIツールが付いてないのか？の問いに対して、
「GUIなどの補助ツールが必要なフレームワークってのは、
単体で使えないほど設計がタコいんだよ」
みたいな解答があったような気がする。
そりゃあそうだけど、やっぱ楽したいよ。

ってなもんで、jFaceDbcで基本情報抜いて、マッピングファイルの細かいところは
手作業でシコシコってパターンが一番多い。。。

913 ：デフォルトの名無しさん：04/04/30 13:44

>>912
俺は一日試しただけだけどリレーション情報抜いてくれるよ。
ただしインサート時の主キー生成の方法とかが何かと問題に
なるのは事実。

カスタマイズは一応できるようになってるけどまあ大体は
DBMS依存だしね。Oracleでは主キーを自動生成したいばあいは
シークエンスを使うのが一般的だけど……ってなあたりから
想像はつくでしょ。
主キー生成をGenericな実装にしようとするとSPと行ロックは
最低限欲しくなるけどこれまたDBMS依存の世界だからねー。

914 ：デフォルトの名無しさん：04/04/30 23:49

>>909
すげー、懐かしい名前だｗ
NASは今はどうなってるの？

915 ：デフォルトの名無しさん：04/05/07 16:37

>>908
Hibernate デュアルレイヤ・キャッシュ・アーキテクチャ
http://www.hibernate.org/4.html#A43

916 ：デフォルトの名無しさん：04/05/07 18:25

MappingFrameWorkって、いわゆるEJBとは違うんですか？

917 ：デフォルトの名無しさん：04/05/07 18:39

いわゆるEJBはMappingFrameworkのひとつ。

918 ：デフォルトの名無しさん：04/05/07 21:21

違うだろ。フレームワークと技術を比べるなよ。

919 ：デフォルトの名無しさん：04/05/08 00:16

フレームワークと技術の違いを述べよ (400字以内)

920 ：デフォルトの名無しさん：04/05/08 04:05

EJB は HYBERNATE や Torque と志向は同じでより大規模向けのもんと解釈してよいんでしょうか。

921 ：デフォルトの名無しさん：04/05/08 07:54

EJBの場合、MappingFrameworkはベースになる機能のひとつにすぎないから志向が同じとは言いがたい。

922 ：デフォルトの名無しさん：04/05/08 09:13

>>919
述べられないが、おれも>>918がただしいと思う。

923 ：デフォルトの名無しさん：04/05/08 22:33

EJBは、ビジネスコンポーネントを作るためのフレームワーク。（だったはず・・・）
ポータビリティーを指向してる点がちと違うのでは。（ポータビリティーなんて嘘だけど）
ORマッピングは、RDBのテーブルへアクセスする方法をOOっぽくするもの。

誕生したときの狙いはこれぐらい違うはずだけど、使い方次第では
同じにもなる。って感じかな？

924 ：デフォルトの名無しさん：04/05/09 00:49

EJBの実装はひとつのフレームワークだと思うんだが
分散オブジェクトを取り扱うための実装とビジネスオブジェクトの実装方法を提供してるんだし

925 ：デフォルトの名無しさん：04/05/09 01:00

そもそも、フレームワークって言葉の定義が、
いまや曖昧だよな。

926 ：デフォルトの名無しさん：04/05/09 04:58

もともと曖昧だよ。
分類のための言葉なんて、そんなもんだ。
かならず境界部分はあいまいになる。

927 ：デフォルトの名無しさん：04/05/09 05:02

>>919
技術 ⊃ フレームワーク
イギリス人とベッカムの違いを述べよ、っていうのと同じ無意味な質問だ。

928 ：デフォルトの名無しさん：04/05/09 14:15

SQL Maps なんかよさそ。チュートリアル読んだだけだけど、こんなのが欲しかった。

ttp://www.ibatis.com/common/sqlmaps2.html

929 ：デフォルトの名無しさん：04/05/09 14:28

フレームワークとは制御の反転だ、"Don't call me. I call you"だという単純化をすれば
EJBもフレームワーク。
これはフレームワークとライブラリの差のはなしか。

930 ：デフォルトの名無しさん：04/05/09 21:13

「もう、かけて来ないで。」
「……つぎは私からかけるから。」

931 ：デフォルトの名無しさん：04/05/09 21:30

>>930
お互いにかけあえる仲
ということは両方男ですね

932 ：デフォルトの名無しさん：04/05/10 08:51

Hollywood principle:
Don't call us, we'll call you.

933 ：デフォルトの名無しさん：04/05/10 11:52

俺用hibernateメモ。

hibernate.cfg.xmlは、SessionFactoryがbuildされる毎に読まれる。
hibernate.propertiesは、Hibernateのイニシャライズ時に１回だけ読まれる。

934 ：デフォルトの名無しさん：04/05/10 20:35

俺用hibernateメモ。

xbm.xmlは、作るのが死ぬほどめんどくさい。

935 ：デフォルトの名無しさん：04/05/10 21:45

>>934
*.hbm.xmlのこと？
Eclipse用のjFaceDbcプラグイン使うといいよ。
DBに接続して、hbm.xmlファイルにしたいテーブルを選択して、
Hibernateへ出力する命令を実行すると、基本的なマッピングファイルが
自動で作られるよ。
あとは、many-to-manyとかのリレーション情報とかが必要なら、そこから
手作業で修正とかすりゃいいし。

936 ：デフォルトの名無しさん：04/05/10 22:12

その点CayenneはCayenneModelerがあるから(ﾟдﾟ)ｳﾏｰだな。

937 ：デフォルトの名無しさん：04/05/10 22:34

でもCayenneは日本語情報が少なすぎ・・・
いいサイトある？

938 ：デフォルトの名無しさん：04/05/11 03:02

Ｃａｙｅｎｎｅってなんて読むの？
カイーネ？

939 ：初期不良：04/05/11 06:39

検索するとすぐ引っかかるポルシェの cayenne は
カイエン、と書いてるね

940 ：デフォルトの名無しさん：04/05/11 07:04

amazonで検索すると、トウガラシを使った健康料理レシピ見たいのがひっかかる罠。

941 ：デフォルトの名無しさん：04/05/11 22:04

カイエンヌ

942 ：デフォルトの名無しさん：04/05/11 22:14

マスコットが、カイエンペッパーだよね。
オレンジ色のにくい奴。

943 ：934：04/05/11 22:48

>>935
さんきゅ。

でも >928 を使った方が簡単そうな気がする。

944 ：デフォルトの名無しさん：04/05/12 06:26

dbutilsとはどちがうの

945 ：934：04/05/12 22:17

>>944
dbutilはselectだけじゃないの？

946 ：デフォルトの名無しさん：04/05/12 22:53

>>945
すこしは調べてから書けよ。無知。

947 ：デフォルトの名無しさん：04/05/12 23:25

DBUtilsは結局SQLを書くことに変わりは無い。
本当に薄いラッパーなので、ResultSet取り出しが若干オブジェクティブになる程度。
その分速度は速いらしいが、DBUtilsの恩恵を受けるためにはQueryRunnerを使いまわしたり
色々面倒だしコード書き直しも沢山あるんで、俺は結局使わない事にした。

あと、無名クラスをガンガン書きまくるハメになるのでは読み辛くて嫌だ。

948 ：デフォルトの名無しさん：04/05/12 23:36

＞あと、無名クラスをガンガン書きまくるハメになるのでは読み辛くて嫌だ。
RowProcessor書けばいいじゃん

949 ：デフォルトの名無しさん：04/05/13 08:24

すんげえ低レベルな話題だが、行ロックが欲しいようなケースってどう
してる？
いわゆるSELECT FOR UPDATEを使いたくなるようなケース。
参照→更新処理って実は大体こうだと思うんだけど。

JDBC2.0では更新可能なカーソルやカーソル名の取得が定義されちょるけど
ドライバによっては対応してないし、マッピングフレームワークとも
なると、正直不透明過ぎてわけわからん。
そもそも思いっ切りDBMS依存だけどデータ一貫性保証のためには絶対に必要、
という困り者。SPにできるんならSPで実装してしまうのが正しいのかな。
これもDBMS依存だけど。

それと、よく困るのは一意制約違反のエラー。これはシステムエラーでも
何でもないから、ちゃんとひろってアプリレベルでの対応が必要に
なるんだけど、SQLExceptionから一意制約違反であることを確かめる
には、DBMS毎のエラーメッセージのパースが必要になる。

950 ：デフォルトの名無しさん：04/05/13 21:47

Web+DBばっかりなんで、参照でロックしたことが無いなー。
いつもは最終更新時間か、レコード更新回数をフィールドに持たせてる。

951 ：デフォルトの名無しさん：04/05/14 07:24

>>950
ようするに、
参照(1)→ユーザがブラウザ側で手入力→更新(2)
で、(1)と(2)の間には無限大になり得るタイムラグがあるから、
その間のロックなんかできませんぜ、ということですよね。

無論その通りで、それゆえに(2)の時に再参照を行って、衝突があったかどうか
確認してるんだろうけど、その際の再参照→更新は
行ロックすべき、ですよね？
そこをatomicにできないんなら、論理的にはその間に衝突が発生する
可能性がある訳だから。

952 ：デフォルトの名無しさん：04/05/15 00:29

俺用hibernateメモ。

データベースアクセスは JDBC でしこしこが一番。

953 ：デフォルトの名無しさん：04/05/15 02:00

俺用hibernateメモ。

Criteriaクラスを使うよりも、HQL使ったほうが高速。
でも気持ち的にはCriteria使いたい。

954 ：デフォルトの名無しさん：04/05/16 22:17

>>944
selectの時に自動的にBeanに放り込んでくれる点はDBUtilと一緒だけど、
SQLMapsならinsert/update/deleteもBeanで自然に操作できる。

955 ：デフォルトの名無しさん：04/05/20 08:37

Hibernateって自動インクルメントのカラムを作らないと
SaveOrUpdateとかカスケードした更新とかって出来ないの？

Hibernateのためにテーブル設計するのもなって思うんだが
漏れは何か勘違いしてるだけかな。

956 ：デフォルトの名無しさん：04/05/20 09:00

>>955
Hibernateを利用したアプリに必要なテーブルを、XDoclet使って作ることもできるし、
既存テーブルをオブジェクトにマッピングさせてもいいし、どちらでも好きな方法とればいいじゃん。
マッピングの基本を見直してみるのもいいかも。
ttp://www.ozacc.com/library/java/hibernate/doc/html/or-mapping.html

957 ：デフォルトの名無しさん：04/05/21 15:23

Exadel - ORM Studio Hibernate Edition
ttp://www.exadel.com/products_ORMstudio.htm

私たちのユニークかつビジュアルな「ドラッグ＆コネクト」アプローチで
Eclipseの実力を拡張する　Exadel ORM Studio (Hibernate Edition)は、
HibernateのORMマッピングを用いて、あなたのアプリケーションに
より効率的な企業データベースアクセスをもたらします。

----

評価版あり。

958 ：955：04/05/22 08:38

>>956
主キーが文字列型の場合ってgenerator classはassignedしか
使えないって思ってるんだけど、そもそもその考えが間違ってるのかな。
それかIdentifierGeneratorを実装するか。
その前に主キーが文字列型って時点で痛すぎか？・・・

959 ：デフォルトの名無しさん：04/05/25 16:42

>>955
uuidを使うとかは？