Java⇔RDBのMapping-Frameworkを語るThre Vol.3
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
NGNG「Java⇔RDBのMapping-Frameworkを語るｽﾚ Vol.2」
http://pc5.2ch.net/test/read.cgi/tech/1086315004/
「Java⇔RDBのMapping-Frameworkを語るｽﾚ
ttp://pc5.2ch.net/test/read.cgi/tech/1049030272/
●まずは、基礎知識と技術選択指針など
[The Fundamentals of Mapping Objects to Relational Databases]
（RDBに対するオブジェクトマッピングの基礎(英語)）
ttp://www.agiledata.org/essays/mappingObjects.html
[O/R-Mappingツールの比較サイト(英語)]
ttp://c2.com/cgi-bin/wiki?ObjectRelationalToolComparison
[Catalog of Patterns of Enterprise Application Architecture]
ttp://www.martinfowler.com/eaaCatalog/
詳細は、>>2以降に。
0449デフォルトの名無しさん
NGNG近似値を得ることを誤魔化しというのも、数とか計算についての考え方がしっかりできてない証拠だと思ってしまうんだけど・・・
0450デフォルトの名無しさん
NGNG0451デフォルトの名無しさん
NGNGいくらでも同一にできると思うのだが。
0452デフォルトの名無しさん
NGNG事前集計の結果を上書きするようにします。
というような改竄系の仕様の乱発を求める顧客の要望には
正直ついていけないというか罪の意識さえ感じてたりします。
0453デフォルトの名無しさん
NGNGなしで何をやれと。
0454デフォルトの名無しさん
NGNG0455デフォルトの名無しさん
NGNGそこでiBATISですよ。
>>445
そこでアジャイルですよ。
ttp://capsctrl.que.jp/kdmsnr/wiki/bliki/?ScopeLimbering
ttp://capsctrl.que.jp/kdmsnr/wiki/bliki/?FixedScopeMirage
0456デフォルトの名無しさん
NGNG0457デフォルトの名無しさん
NGNGSQLガリゴリ書いて、Map配列
コレ最強
0458デフォルトの名無しさん
NGNGま、Hibernateはその分、バイトコード弄りしてくれるわけだが。
iBatisのSQLMapはCommons DBUtilsまんまでぱくりやろ。
0459デフォルトの名無しさん
05/01/21 00:00:220460デフォルトの名無しさん
05/01/21 00:28:00なんかほとんど紹介だけって感じだったけどさ...
0461デフォルトの名無しさん
05/01/23 01:29:15見てきたけど、ほんとに紹介だけって感じだった。
導入とGUIを使ってのマッピングと、簡単なデータ操作の方法という感じ。
Cayenneは、なかなかその次のフェーズの記事がでないな。。
0462デフォルトの名無しさん
05/01/23 05:32:44結局Toplinkが一番いいという話になっててちょっと笑った。
0463デフォルトの名無しさん
05/01/28 01:27:580464デフォルトの名無しさん
05/01/30 18:22:060465デフォルトの名無しさん
05/02/06 01:30:320466デフォルトの名無しさん
05/02/06 02:14:240467デフォルトの名無しさん
05/02/06 12:42:240468デフォルトの名無しさん
05/02/06 14:08:320469デフォルトの名無しさん
05/02/06 17:42:06そんなあなたにiBatis
0470デフォルトの名無しさん
05/02/07 10:38:280471デフォルトの名無しさん
05/02/07 10:48:19イーバティス？
0472デフォルトの名無しさん
05/02/07 13:27:430473デフォルトの名無しさん
05/02/07 22:36:17雑誌で簡単な記事とかならあったけど、ネット上で日本語情報はほとんど皆無。
英語だけど、ここのSQL Maps Tutorial見ると、こんな感じかあってのが分かる。
http://www.ibatis.com/common/download.html
0474デフォルトの名無しさん
05/02/08 01:22:31ttp://www.onjava.com/pub/a/onjava/2005/02/02/sqlmaps.html
とはいえ、本家のチュートリアルで十分かな。
iBATISの売りは、シンプルなことなんだし。
0475デフォルトの名無しさん
05/02/08 22:02:13（新） hibernate.cache.provider_class net.sf.hibernate.cache.EhCacheProvider
（旧） hibernate.cache.provider_class net.sf.ehcache.hibernate.Provider
0476デフォルトの名無しさん
05/02/09 01:40:18外部参照を無意味なID値でやるってことだと、かなりDB設計技法が変わって周囲からの抵抗が予想され.....
0477デフォルトの名無しさん
05/02/09 02:39:050478デフォルトの名無しさん
05/02/09 14:49:06ありがとうございます。
見てみます。
0479デフォルトの名無しさん
05/02/10 07:45:45紐付けされた別オブジェクトの属性で
ソートすることはできますか？
.add( Expression.eq( "master.name", new String("ほげほげ"))
で、検索条件として使うのはOKなんですが、
.addOrder( Order.asc("master.name") )
としてソート条件として使おうとすると実行時に例外となって
しまいます。
0480デフォルトの名無しさん
05/02/10 19:57:37master.nameはselectしてる？
そうじゃないとだめなDBもあるよ。
>new String("ほげほげ")
なんでわざわざnewしてんの？
0481デフォルトの名無しさん
05/02/14 03:02:570482デフォルトの名無しさん
05/02/14 03:41:30とりあえず、継承のマッピングはHibernateの方が強い。
0483デフォルトの名無しさん
05/02/14 23:33:16joined-subclassでマッピングしてるとそのぶんleft joinするからMySQLつかうと結構問題。
0484デフォルトの名無しさん
05/02/15 00:12:300485デフォルトの名無しさん
05/02/15 00:54:17ttp://objectstyle.org/cayenne/release-notes/RELEASE-NOTES-1.2M2.txt
0486デフォルトの名無しさん
05/02/15 02:15:29しかし一番継承のマッピングするのはキモの部分だったりする
0487デフォルトの名無しさん
05/02/15 10:30:52日本語のシンタックスエラー。"一番"の辺りに。
クエリーを投げなおしてください。
0488デフォルトの名無しさん
05/02/18 14:18:15ttp://hp.vector.co.jp/authors/VA027994/blanco/blancodb.html
国産みたい？
0489デフォルトの名無しさん
05/02/19 22:07:590490デフォルトの名無しさん
05/02/19 23:04:53Bean 使ってる場合のリフレクション除けば、JDBC 直と変わらんだろ。
おまいの SQL が悪いか、コネクションプールしてないかだろ。
0491デフォルトの名無しさん
05/02/19 23:39:49一回のSQLで大量のデータを取得するときは、
遅いんじゃないの？？
0492デフォルトの名無しさん
05/02/20 00:21:34大量のデータをfetchした時は、そのデータをHDDから読み出したり、ネットワーク経由で送る時間の方がずっと大きいので、dbutilのオーバーヘッドなんか全然関係なくなるのでは。
0493デフォルトの名無しさん
05/02/20 01:28:46されてまう。つくりの問題。
0494デフォルトの名無しさん
05/02/20 01:42:08Listじゃなくてiteretorで返すやつ低レベルAPIじゃなくてもう一皮ラップしたやつ用意してくれればいいのにね。
あと動的SQL対応。
0495デフォルトの名無しさん
05/02/20 12:42:23のが一番の問題かな。Cayenneはこの辺どうなのかなー。
Hibernate3が待ち遠しい。
0496デフォルトの名無しさん
05/02/20 17:20:51それはJavaの言語仕様の問題なので、Hibernateのone-to-oneは使わず、one-to-manyで実装しておいて、one-to-oneなプロパティを自分で作る。
List getDatas()
でone-to-manyにして
Object getData(){
if(getDatas().size() == 0) return null;
return getDatas().get(0);
}
というone-to-oneエミュレーションなプロパティを作る。
0497デフォルトの名無しさん
05/02/21 22:07:00dataは複数形。単数形はdatum。
以上、トリビアでした。
0498デフォルトの名無しさん
05/02/21 22:29:50以上、トリビアでした。
0499デフォルトの名無しさん
05/02/22 20:36:17以上、オリビアでした。
0500デフォルトの名無しさん
05/02/22 22:16:07以上、オレオレでした。
0501デフォルトの名無しさん
05/02/23 09:17:24でもそれは健康を害するトランス脂肪を含んでいて、
カリフォルニア州では、子供に食べさせることを全面的に禁じる訴訟が起きちゃったんですね。
以上、オレオでした。
0502デフォルトの名無しさん
05/02/23 10:09:350503デフォルトの名無しさん
05/02/23 19:41:44外のクッキー自体は大丈夫だよね
知るかよ
0504デフォルトの名無しさん
05/02/25 14:50:00にもあるかと思うんですが、Hibernateって、複合キーを扱えないって聞いたんですけど
本当ですか？
例えば、下のような会社、部署、従業員って３つのテーブルの関連はうまく扱えないのでせうか？
会社
PK：comp_id
部署
PK：comp_id, dept_id
従業員
PK：comp_id, dept_id, person_id
「うまく扱う」っていうのが抽象的で申し訳ないんですけど。
0505デフォルトの名無しさん
05/02/25 15:34:250506デフォルトの名無しさん
05/02/25 23:16:43うそです。
ところで、複合キーってなんかメリットあるの？
0507デフォルトの名無しさん
05/02/26 01:35:20いる。
そういう現実がある以上、HibernateなりなんなりのORマッピングツールが
現実にマッチしていないとしたら問題だと思うね。こっちがいくら、PKにはPK用に
項目を設けてくれといったところで、現実にマッチしてない段階で「つかえねえ
ツールだな」と解釈されてしまう。
そういうのって勿体ないよね。HibernateもCayenneもEOFも複合キーから遠ざか
ろうとするのは良いんだが、現実問題を解決してくれ、という気持ちにもなるわな。
0508デフォルトの名無しさん
05/02/26 03:50:40やるなら新規。
0509デフォルトの名無しさん
05/02/26 07:34:26現実問題として、DB屋に複合プライマリキーに慣れ親しんでいる人がいっぱいいても、コーディングが面倒になるからやめて欲しいのは確か。
そういう現実がある以上、DB屋が現実にマッチしていないとしたら問題だと思うね。
DB屋がいくら、PKを含んだ複合キー項目を設けてくれといったところで、現実にマッチしてない段階で「つかえねえDB屋だな」と解釈されてしまう。
そういうのって勿体ないよね。DB屋も複合キーで美しい設計にしようとするのは良いんだが、現実問題を解決してくれ、という気持ちにもなるわな。
0510DB屋
05/02/26 12:20:24あほか、大規模システムのコアは DB だ。
基幹システムのような場合、DB には Java だけでなく .net や COBOL
などからもアクセスされる。Java はただの数あるクライアントの 1 つに過ぎない。
そんな中、1 言語の中のたかが 1 ライブラリの都合なんか知るか。
思い上がりも程々にな。
あと、DB アクセスロジックを Java の中に持つなバカ。
共通化って Java の中の狭い中しか見てないだろ。
ストアドにして、どの言語からでも使えるようにしろ。
Java だけを見ていたい気持ちは分かるが。
まー、Java しか知らん香具師ほど、この気持ちは強いだろな。
0511デフォルトの名無しさん
05/02/26 13:53:000512デフォルトの名無しさん
05/02/26 14:44:42ライブラリの都合の問題とかじゃなくて、そもそもそういう設計が良い設計だとは
思えんのだが…って板違いだな
0513デフォルトの名無しさん
05/02/26 14:53:38509の言う「現実」ってのは「マッピングツールが対応してない」「コーディング
が面倒」ってこと？ 複合キーがシステム的におかしいというならわからんでも
ないけど、コーディングの都合で設計を変えてくれってのは理解しがたい。
まぁ、複合キーの是非に関してはおいといて、システム組む時にはやっぱり
DBありきだと思うよ。
なお、個人的には複合キーは嫌いではないし、ストアドはあまり好きでない。
0514デフォルトの名無しさん
05/02/26 15:00:53複合キーのメリットってなに？
メリットにくらべてデメリットが大きいなら、設計を変えるべきだとは思う。
デメリットとしては、SQLが長くなることやら、ORマッピングに限らずプログラム上でいろんな仕組みが使いにくくなることやらあげれるんだけど。
メリットってなに？デメリットをうわまわるメリットがあるなら、考えを改める。
ところで、Hibernateで複合キーが使えないって、どういうこと？
とりあえずは使えるよね？
0515デフォルトの名無しさん
05/02/26 15:03:30それなら、いっそう、いろいろな環境から使いやすい単純なキーにしておいたほうがいいと思うが。
VBのコンポーネントでも、複合キーと相性が悪いものはあるわけだし。
Delphiのコンポーネントは複合キーだと使いにくかったし。
0516デフォルトの名無しさん
05/02/26 18:03:43あるシステムではキーになってても連携する隣のシステムじゃその値を変更したいなんてことは良くあると思うし。
まあ、スレ違いだな。
0517デフォルトの名無しさん
05/02/26 18:33:44ER図上でカーディナリティも理解できることから、自然キーがいいという意見はもっともだ。
実際、自然キーで設計されたテーブル群のほうが多いだろう。
しかしより基本的なレベルに「キー値は不変の情報を用いる」という原則がある。
最初の設計時には不変に思えた自然キーが、機能追加時に変更の必要が出てくることがある。
これは自然キーの変更を迫るような設計変更が悪いのではなく、
ビジネスの変更に応じてキーを変えられない当初の設計が間違っている。
>>510の考えには全面的に同意する。
異なる環境、言語からのアクセスも並列に存在することは当然想定すべきだし、
ストアドプロシージャというデータベースアクセスの抽象化手段も使わない手はない。
(パフォーマンス向上という副作用までついてくるんだし)
その上で、キーには代理キーを使うべきだ。
0518デフォルトの名無しさん
05/02/26 21:04:470519デフォルトの名無しさん
05/02/26 21:06:030520518
05/02/27 00:09:20対して問題になってないんだけど、次期システム開発なんかに巻き込まれて
「ＤＢが変わります」とか言われた時に、同じＤＢならストアドが流用できるのに
とか考えてしまう。
まあ結局はシステムが変わってるのでストアドも作り直しになっちゃったりもする
んだけどなw
0521デフォルトの名無しさん
05/02/27 01:16:00> 共通化って Java の中の狭い中しか見てないだろ。
> ストアドにして、どの言語からでも使えるようにしろ。
当面Javaでやって、もし他から必要ならWebサービスで呼び出せば充分かと。
必要かどうかもわからない共通化のために、開発環境の充分に整いにくいストアドでやる必要はなさげ。
0522デフォルトの名無しさん
05/02/27 01:35:11なるほど、Web サービスなら .net で組みやすいな。Java を使う必要もない。
で、COBOL から Web サービスの呼び出しって実績あんのか？
HTTP でパフォーマンス落としてまで Web サービスっていいか？
0523デフォルトの名無しさん
05/02/27 02:20:20えっと、必要かどうかわからない共通化にコストかけるよりはいいと思う。
0524デフォルトの名無しさん
05/02/27 02:22:410525デフォルトの名無しさん
05/02/27 02:59:00共通化すること。DBが他メーカーのものに変わっても、そのまま動いてくれる。
一方でストアドプロシージャは、ちゃんと作ればとにかく速い。いろんなテーブルのいろんな
ところをちょっとずつ更新、なんて処理もそつなく高速にこなしてくれる。
実際DB・APPサーバの通信がボトルネックになる事もあるから、その辺も考慮すると、
全部が全部ORマッピングというのも考えものだよな。
まあCayenneやEOFの吐き出すダサいSQLを許容してる俺がいうのもなんなのだけど...
0526デフォルトの名無しさん
05/02/27 03:16:370527504
05/02/28 09:05:24なんかレスがいっぱいあって個別にレスできないのは申し訳ないんですけど・・・
みなさんありがとう。
で、Hibernateの話ではなくなってしまってスレ違いな話題ではあるんですが、
ちょっとマジレスきぼん。
>>504
で出したテーブルは複合プライマリキーだから設計がよくないって意見が大半のような
気がするんですけど、複合プライマリキーを使わないでテーブル設計する場合って↓
みたいなのでいいんですか？
会社
PK：comp_id
部署
PK：dept_idとPKじゃない：comp_id
従業員
PK：person_idとPKじゃない：comp_id, dept_id
それとも、まったく別の形？
自分でDB設計することってほとんどないんだけど、こんな形のテーブルばっかり
扱ってきたので、普通なんだと思ってました。
識者の方、お願いします。
0528504
05/02/28 09:34:22この形（複合キー）のテーブルで違和感がなかったのは
・複合キーすべてを指定してSELECTしたら、存在してれば、戻ってくるのは必ず１行
・同じ値（例えば従業員）のレコードを挿入しようとしてもDBではじいてくれる。
っていうメリットがあるような気がするんですけど。どうですか？
0529デフォルトの名無しさん
05/02/28 11:01:59> ・複合キーすべてを指定してSELECTしたら、存在してれば、戻ってくるのは必ず１行
複合キーにしなければ、1つのキーだけでも指定できる。
複合部分は主キーではないインデックスにすれば同じことが出来る
> ・同じ値（例えば従業員）のレコードを挿入しようとしてもDBではじいてくれる。
主キーにしなくてもできる
レコードを特定するのに複数の値が必要になることのデメリットの方が多いと思う。
このポリシーだと、関連するたびにキーが増えていく。
たとえば、売上に担当した従業員を保持しようと思うと、会社と部署のコードを持つ必要がある。
会社は部署からたどれるので、わざわざ従業員に持つ必要がない。
部署は従業員からたどれるので、わざわざ売上に持つ必要がない。
0530デフォルトの名無しさん
05/02/28 11:54:42レスありがとう。
理解が足りなかったらごめんなさい。
>複合キーにしなければ、1つのキーだけでも指定できる。
>複合部分は主キーではないインデックスにすれば同じことが出来る
>主キーにしなくてもできる
と、いうことは極端に書くと以下のような設計がよいということなんですかね？
従業員
PK：代理キー＋重複なしの複合インデックス（person_id, dept_id, company_id）
なんか、勘違いしていたような気がするんですが、設計上よくないのは、
複合「プライマリキー」で、キーは代理キーにして、
複合キーでやりたかったことは他の列で複合インデックスはってやれって感じなんでしょうか？
>レコードを特定するのに複数の値が必要になることのデメリットの方が多いと思う。
>このポリシーだと、関連するたびにキーが増えていく。
はい。そう思います。
と、いうことで、まとめると↓でFA?
会社
PK：comp_id
部署
PK：代理キー＋重複なし複合インデックス（dept_id,comp_id)
従業員
PK：代理キー＋重複なし複合インデックス（person_id, dept_id)
0531デフォルトの名無しさん
05/02/28 12:22:50dept_id が会社内で一意で、person_id が部署内で一意だとすると、
従業員テーブルのインデックスは、(person_id, dept_id, comp_id) になるんじゃない？
結局従業員テーブルに関連テーブルのキーを入れことになるので、
俺はこういう場合は複合キーにしたいんだが……。
代理キーを使う利点って、社員を外部キーに持つテーブルのカラムが
無駄に増えなくて済むって点があると思うけど、Hibernate はこういう複数のカラムを
キー用のクラスに隠蔽してくれるんじゃなかったっけ？
ただ、そのキー用のクラスを使うのがけっこう煩わしかったような気もするけど。
Hibernate はあまり使い込んでないから外してたらすまん。
0532デフォルトの名無しさん
05/02/28 13:01:17なのに、なぜかHibernateで複合キーが使えないような感じで議論が展開してる。
Hibernateじゃなくても、複合キー使うのはだいたいわずらわしい。
0533デフォルトの名無しさん
05/02/28 13:02:360534age
05/02/28 13:35:33>Hibernateじゃなくても、複合キー使うのはだいたいわずらわしい
って、どういうこと?
0535504 = 530です
05/02/28 14:09:57>>531
>代理キーを使う利点って、社員を外部キーに持つテーブルのカラムが
>無駄に増えなくて済むって点があると思うけど、
ですね。そのとおりだとは思っているのですが・・・>>476にもあった
>外部参照を無意味なID値でやるってことだと、
>かなりDB設計技法が変わって周囲からの抵抗が予想され.....
私もなんとなく、外部参照が代理キーになるってのが気持ち悪いというかなんていうか・・・
なので、複合キーでも特に問題があるように見えませんでした。
>Hibernate はこういう複数のカラムを
>キー用のクラスに隠蔽してくれるんじゃなかったっけ？
とりあえず、複合キー自体は扱えるようなので、
これからHibernate使って勉強してみたいと思います。
>>532
>なのに、なぜかHibernateで複合キーが使えないような感じで議論が展開してる。
いえ、>>506にだれも反論していないので複合キーは扱えるという結論なんだろうと思ってました。
で、それとは別に、そもそもなぜ、複合キーか？っていう議論に発展していて、
スレ違いとはわかりつつ、続けさせてもらってました。
で、大半の意見としては、>>532のように
・複合キー使うのは（DBのクライアント側からすると）だいたいわずらわしい。
というところなんでしょうか？
0536デフォルトの名無しさん
05/02/28 14:43:21SQL直書きなら連結のための条件が増えて面倒だし、OCXやVCLのコンポーネントなんかでも複合キーになると不便だったりする。
0537デフォルトの名無しさん
05/02/28 14:47:12逆にオレの場合、なんならOIDがキーでもかまわないくらい、実際に必要な値をキーにしたくない。
OIDだとはげしくDB依存するから、シリアル値をキーにするけど。
0538デフォルトの名無しさん
05/03/02 00:26:40ttp://blog.hibernate.org/cgi-bin/blosxom.cgi/2005/02/28#3announce
ttp://www.hibernate.org/Download/DownloadOverview
0539デフォルトの名無しさん
05/03/04 10:34:57できるライブラリってないいんですか？
0540デフォルトの名無しさん
05/03/04 11:11:51C++はわからんけど、.NETでORマッピング使いたいなら、
NHibernateとかいうものがあるぞ。
あとはC++のｽﾚへ逝け
0541デフォルトの名無しさん
05/03/05 14:14:41既存のテーブルに対してJavaクラスを自動生成したい場合って
そこでXDoclet使う意味は無いですかな？
オープンソースJavaプロダクツという本には
既存のテーブルからJavaクラスを自動生成する方法が
のっておらずXDocletタグつきのJavaソースコードから
テーブルを自動生成する方法しか乗ってなかった orz
なんかええサンプルない？
それより、XDoclet2 + Maven2ﾏﾀﾞｰ?
0542デフォルトの名無しさん
05/03/05 14:24:38遊んでてぜんぜん生産性が上がってないんだよな
0543デフォルトの名無しさん
05/03/05 15:25:59使う意味あると思うよ。
クラス+hbm.xml書く手間と、クラス+XDocletタグ書く手間じゃ
大差ないし、マッピング情報をひとつのファイルに集約できる。
サンプルはmiddlegenでぐぐれば見つかるっしょ。
ただし、結構間違えたの吐くので要注意。
0544デフォルトの名無しさん
05/03/05 19:50:10まとめて一つのコレクションにつっこんでから、プログラム内で仕分けをするほうが
一般的ですか？
where属性の中にHQL識別子が使えれば迷わずwhere属性を使うのですが...
0545デフォルトの名無しさん
05/03/05 21:27:000547デフォルトの名無しさん
05/03/07 01:56:03「Javaにかじりつく」の意味がわからないが
2chで見た憶測かな？
Javaを初めて使った頃に比べれば生産性は大幅にあがってるよ。
HibernateやCayenneは明らかに生産性を上げるものだね。
JDBCでSQL文をベタ書きするよりは明らかに
でっかい生産性を上げているね。
べた書きするとテーブル仕様変更したとき厄介だしね。
カラムを追加したときも面倒くさいし。
■ このスレッドは過去ログ倉庫に格納されています