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

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

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に限ればロギングが
Log4jっていうのがどうも気に食わない

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/

info@ebrain21.com


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が残って メンテするやつも勉強になるし

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


38 :女□:03/04/02 01:21
DBのフレームワークってSQLを手で書かなくていいようにするのが目標なのかね
SQLは手でモロに書くものだと思ってるから かなり受け付けない

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

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だろうが、未知のより進歩的なストレージだろう
>がシームレスに使えることが目標なのよ。

DBにあんな皮こんな皮かぶせて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 :名無しさん@Emacs: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にデータベース指定しないで単に「jdbc:***: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の中にJavaのコードが入ることを避けるために、
Taglibや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
それ笑えるな
本当に女で13歳だったらなかなかすごいかも知れんなw

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を実行したかによってスピードなんて変わってくるからね。
1000件で2秒前後ならそんなもんでしょ。

そこまでクリティカルなスピードを求められるなら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/
2chスレ
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#を使っている罠(w

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の言うようにしたいと思います
ただ、テーブルの行数が多くなりますが
dbの設計って言うのは何千行でも何万行になったとしても
こういう作り方をした方が良いのでしょうか?
聞いたところによると、最初の設計者が
あまりひとつのテーブルに行が多いとダメ見たいなことを言ったらしくて
そういう使用になったそうです
いちおうオラクル6なんですがオラクルなら何千何万行でもOKですよね

207 :デフォルトの名無しさん:03/06/14 13:05
セクシー画像を生クリック☆!(閲覧無料)
http://endou.kir.jp/moe/linkvp.html

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

>>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

無意味な事してんな(w

インデックスの張り方とかテーブルの列の順序とか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 って3日前に知ったばっかりでした。


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スクリプトが一番参考になるんじゃないかなぁ。
でもまだタグライブラリの方は動かないの結構多いけど(w

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

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

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

307 :デフォルトの名無しさん:03/07/16 13:19
WebObjectsの7万って、イメージ的に諸刃の剣だよな。
以前は700万だったから、イメージ的なありがたみ?があったけど、
いきなり7万になったら、「?」って思う。
70万だったら「ふむふむ、よさげだけど高いな」って感じか。
結局、モノは凄いのに認知されないんだよな。マイナーだし。

308 :デフォルトの名無しさん:03/07/16 17:10
>>306はイタイいな。


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

310 :デフォルトの名無しさん:03/07/16 19:21
すごさをアピールしようとして掲示板システムを選び、
その必然性の無さがアピールされてしまってシパーイ(w
いや、EOF最強なんだけどさ、ツブシが利かねんだよね。

311 :fusianasam:03/07/16 19:32
>>310
必然性がないから、フリーでばらまいていると思う。これでビジネスやろう、なんて人は無いと思うが(w
サクーシャもそこらへんわかってんじゃないの。別にクラスタリングが必須というワケでもなさそうだし。ただその機能もサポートしてるってだけでしょ。
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
またそんな出鱈目を。マカーの妄想ですか。禿信者はこれだから困る。
いつもはじめじゃないといけないコンプレックスの固まりだな。プッ.

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


316 :デフォルトの名無しさん:03/07/16 22:07
何も知らないアフォが吠えてるな。
信者マカーは、EOFなんて知らないんじゃねーの?w

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("5スレ");
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がすばらしく設計されていたとしても、
アプリケーション全体をオブジェクト指向の視点でみると
不自然な設計になりませんか?

たとえばアプリケーションの固定値(環境変数等)をDBで持っている場合、
自分は固定値を管理するクラスをつくろうと思いますが、
何らかの形でDBアクセスするためのクラスを渡す機構が必要になるでしょうし、

単純にユーザIDが1番のレコードの名前を変えたいという処理がリクエストを
またいでいた場合、DBアクセスを減らすためにユーザをマッピングしたクラスを
保持していなければいけなくなります。その際に自動生成されたクラスはいじりたく
ないのでラッパークラスの作成を考えてしまうのですが、
そうすると更新の時はやっぱりマッピングクラスを何らかの形で渡さなければ
いけないのであんまし意味がなくなります。

どちらにしろSQL文を埋め込んでしまうとオブジェクト指向としてはきれいな設計
になるのではないかと思います。

私は、ソースにSQL文を埋め込むのはかっこわるいと思っています。
しかし、フレームワークを使うと設計が前時代的になるのではないかと思っています。
そこがトレードオフなのかもしれませんが、

要するによい設計法やパターンがあればそれを教えて欲しいと思っています。
よろしくお願いします。


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で持っている場合、
>自分は固定値を管理するクラスをつくろうと思いますが、
>何らかの形でDBアクセスするためのクラスを渡す機構が必要になるでしょうし、

たいていのフレームワークでは、DBアクセス用クラスのインスタンスを
アプリケーション側で受け渡すような必要は無い。
もっとマシな設計になってるよ。

>単純にユーザIDが1番のレコードの名前を変えたいという処理がリクエストを
>またいでいた場合、DBアクセスを減らすためにユーザをマッピングしたクラスを
>保持していなければいけなくなります。その際に自動生成されたクラスはいじりたく
>ないのでラッパークラスの作成を考えてしまうのですが、

リクエストを跨いだトランザクションをサポートしたフレームワークなら、
自動生成されたクラスをいじる必要は無い(そのまま保持してればいい)。
それと、今時はデータオブジェクトクラスの自動生成は行わないフレームワークの
ほうが主流のような気が。


342 :デフォルトの名無しさん:03/07/27 23:46
>>338
禿同。

343 :デフォルトの名無しさん:03/07/27 23:48
そういえばよく日付とか扱うよな。
あれってCURRENT TIMESTAMPとか使っちゃったりしてさ。
DB中心で扱うことが多いんだけど(たまたまね。)
日付はJAVA(アプリサーバ)とDBサーバどっちで扱ったほうがいいと思う?


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/turbine-user@jakarta.apache.org/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でエラーでたw
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もSQAがあるんじゃない?

となると、知ってる名前じゃなきゃだめってことかなぁ?

423 : :03/08/03 11:03
>>419 ブランドの力をなめてはいけない。 ブランドはブランドを維持するために
莫大な投資と宣伝してるわけで…。



424 :デフォルトの名無しさん:03/08/03 11:13
>>422
SQAじゃねえや、SRAのまちがいね。すんません。

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
意外と賛同者多いんでちょとビクーリw

>>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
カンケーないっすけど、おまえら、オッパイ好きですか?

オレ様は、世界中の誰よりもオッパイが大好きだ。Dカップぐらいがいい。

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。

まあ、上記の3つはどうでもいいような気もするが。


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
ViewはViewだ。もっとわかりやすくいうなら外部スキーマだ。わかったか。

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
そうなんだけど、英語読まない奴そこら中にいるよね。
俺の隣の席のやつとかw

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の中心部分使えないのダサすぎw
今更接続プーリングなし、自前トランザクション管理ですか?

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
>>1 >>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コマンド打てばいいのか・・・

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

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

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