トップページ⇒tech
1001コメント353KB

Java⇔RDBのMapping-Frameworkを語るThre Vol.3

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさんNGNG
Prevoius Thread
「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以降に。
0083デフォルトの名無しさんNGNG
>>82
両方とも
0084デフォルトの名無しさんNGNG
>>83
ま、少なくとも、仕組みとしてはあるデータだけに属性を追加というのはできない。
どうにかして実現するとしても、属性がデータによって変わることがあるものは、RDBではかなり表現しづらい。
なんとかデータを格納しても、検索やりづらいし。
0085デフォルトの名無しさんNGNG
その属性の値が存在しないということを表現するために
nullってモンがあるわけだけどね。
0086デフォルトの名無しさんNGNG
Hibernateで、TorqueみたくRDBのスキーマドキュメント生成するツール
ってあるんですか？
0087デフォルトの名無しさんNGNG
Hibernateで用意されている必要性がわからん。
0088デフォルトの名無しさんNGNG
>>85
nullがあるとしても、1万件のデータのうち、ひとつのデータにだけある属性のために9999件のデータにnullを入れるのはムダだし。
ほかのデータには別の属性が複数あったり、ある属性は複数のデータがもっていたりすると、ひとつの表で表現するのは非常にムダ。
alter tableしてinsertする、というオペレーションも避けたいし。
また、そのうちのある属性は配列になっていたり、複合属性になってたりすると、データの表現だけで大変な労力が必要になってくる。
データの整合性を保つというデータベースの役割は果たせなくなるし。
0089デフォルトの名無しさんNGNG
>>85
そのデータにはそもそもその属性がないのか、属性はあるけども値が割り当てられてないのか、判断できないね。
0090デフォルトの名無しさんNGNG
>>88
そこまで統一性が無い場合って、例えばどんなデータでしょうか。(イメージつかめてない)
(まぁ少なくともJava⇔RDBからは外れそうだけど。)
0091デフォルトの名無しさんNGNG
>>90
代表的なのはアンケート情報
0092デフォルトの名無しさんNGNG
あ、あとRDBばっかり触ってると、RDBで表現できない分野のデータについて想像できなくなる
0093デフォルトの名無しさんNGNG
>>91
アンケート情報は定型化しなきゃ駄目じゃん、と思ったけど、何種類も違うや
つを一緒に管理する場合と理解してOK?
0094デフォルトの名無しさんNGNG
>>93
1回のアンケートは定型化できても、次回は少しだけ項目がかわるということはよくある。
実際に聞きたい項目は定型化していても、あとの質問での答えを引き出すための質問は質問対象によって変わるということもありうるし。
0095デフォルトの名無しさんNGNG
バカ？

顧客ID アンケートID アンケート質問 アンケート回答

みたいなテーブルつくっておけばいいだけじゃん。
項目増えてもオッケーでしょ。
009695NGNG
まあ上の例だとまずいかな。
ID・質問マスタは別に用意すべきだろう。

でも、RDBで十分対応できる範囲だな。
0097デフォルトの名無しさんNGNG
と、アンケートを甘く見てると、そう思うわけだね。
0098デフォルトの名無しさんNGNG
>>96
複数回答ありの項目があると、結構簡単に破綻するけどね。
0099デフォルトの名無しさんNGNG
>>95
まぁ、お前が一番バカだってこった。
0100デフォルトの名無しさんNGNG
>>98
そういう場合は単に枝番を振るなりすればいいんじゃないの？

顧客ID アンケートID 枝番 回答ID

これでオッケー
前の絡む3つが主キー候補
0101デフォルトの名無しさんNGNG
>>100
複数設問、複数回答、修正可能、履歴ありの項目があると、結構簡単に破綻するけどね。
0102デフォルトの名無しさんNGNG
>>101
複数設問って、どんなだ？
普通、アンケートって複数設問があるけど、そういう意味じゃないよね。

俺も後で考えたけど、選択入力の項目と自由入力の項目があって
自由入力はしばしば「その他」を選択入力として選んだ場合、
とかだったりするのが、汚くなりやすい要因なのかなあと思ったり
したですよ。
多分FKによる外部参照制約をつけにくくなったり、ほとんどの場合に
NULLであるようなVARCHAR(4000)のカラムが必要になったりとか。
0103デフォルトの名無しさんNGNG
postgresでtext使ってハイ終了
0104デフォルトの名無しさんNGNG
>>103
じゃ、どんなテーブルでも ID と text 1個でハイ終了･･･
0105デフォルトの名無しさんNGNG
>>101
履歴をどう利用したいかにもよるだろうけど
履歴テーブルをドン、と作っておいて
トリガーでコピーとかもアリ
0106デフォルトの名無しさんNGNG
>>100
じゃあ、複数回答のある項目の中に複数項目が含まれるときは？
「お持ちのパソコンと、インストールしている主なソフトとそのメーカーを答えてください。」みたいな。

ありうる設問に対してすべて対応できるようなテーブル設計って、気が狂いそうになる。
0107デフォルトの名無しさんNGNG
>>104
そこにXML形式のデータ入れておけば終了。
0108デフォルトの名無しさんNGNG
>>107
で、そのXMLの中のひとつで検索したい場合にインデックスも
張れないと。






　　　ってか、おまえら Mapping Framework を語れ。
0109デフォルトの名無しさんNGNG
DBUtilsも入れてもいい？
0110デフォルトの名無しさんNGNG
>>109
>2 >4 >6
0111デフォルトの名無しさんNGNG
>>103はVARCHAR(4000)に対するツッコミだろ
0112デフォルトの名無しさんNGNG
CLOBが使えなかった頃の典型的なテクという気もするけど。
CHARと違って実際に4000バイトの領域が自動的に使われちゃう
という訳ではないからね。
0113デフォルトの名無しさんNGNG
>>88
ムダかどうかはここでは別の話なんで措いておくとして、
そういうデータの表現がRDBだと難しくてXMLなら容易だと
考えるのはばかげている。
0114デフォルトの名無しさんNGNG
>>113
RDBではひとつの表では表現できなくて、XMLで非常に素直に表現できるのは事実だが。
0115デフォルトの名無しさんNGNG
>>89
RDBではそもそもそのふたつを区別しない。
XMLでもおなじことだけど。
0116デフォルトの名無しさんNGNG
>>115
XMLであれば、タグを書かなければ表現できる
0117デフォルトの名無しさんNGNG
>>114
なんで一つの表で表現しなきゃならんのだ？

＃>>114にとって「2つ以上の表を扱うのは難しい」ということ？
0118デフォルトの名無しさんNGNG
>>117
ひとつのデータの集まりを表すために２つ以上の表を扱うのは、かなりめんどくさいよ。
マッピング使えばある程度楽にはなるけど。
素直に表現できるのであれば、素直に表現できたほうがいい。

ま、表をごりごりつなげるのが苦ではないなら、RDB使ってればいい。

実際には、ほとんどのシステムで、RDBでの苦よりRDBでの楽が勝るから、RDBを選択することになるんだけど。
0119デフォルトの名無しさんNGNG
>>117
素直に表現することの価値がわからなければ、わからないだろうね。
0120デフォルトの名無しさんNGNG
よーし次はNDBだあ
0121デフォルトの名無しさんNGNG
>>119
君にはNDBがオススメだ！
0122デフォルトの名無しさんNGNG
>>118
CODASYL頭のSEがRDBを否定しているのを見てるみたいだな。

問題領域をRDBにマッピングするのはめんどくさくて、XMLに
マッピングするのは「素直」？
やっぱり単にRDBの使い方を知らんだけのようにおもうが...。
0123デフォルトの名無しさんNGNG
>>122
話の流れが読めん奴だな。
話題に出てるような、属性がデータごとに異なるものをRDBにマッピングするのはめんどくさくて、XMLにマッピングしたほうがより素直に表せるという話なのだが。

一般的に言えば、属性が動的に変わるデータはRDBで扱いづらい
0124デフォルトの名無しさんNGNG
> ひとつのデータの集まりを表すために２つ以上の表を扱うのは、
> かなりめんどくさいよ

> ま、表をごりごりつなげるのが苦ではないなら、RDB使ってればいい。

DQN決定
在る意味Map以上に凄いかもね君。
0125デフォルトの名無しさんNGNG
何のために正規化しているのか…
0126デフォルトの名無しさんNGNG
>>123
いや、だからどの程度の「動的」を想定してんの？
アンケート程度では、正直RDB否定論の根拠としては薄いと思うよ
0127デフォルトの名無しさんNGNG
>>125
正規化されたデータを２つ以上のテーブルに分割する場合がめんどくさいんだよ。
アンケートの場合でも、属性を無限に増やしていけば、正規化されたままで表現はできるわけだから。

>>126
別に否定してるわけではないし、XMLの方がより素直に表現できるといってるだけ。
0128デフォルトの名無しさんNGNG
>>127
＞正規化されたデータを２つ以上のテーブルに分割する
正規化されてねぇんだよ、それ
0129デフォルトの名無しさんNGNG
>>124
正規化してテーブルの数を増やすと、実装の手間が増えるのは事実。
それが許容できる範囲かそうでないかは別の話で。
0130デフォルトの名無しさんNGNG
>>128
データ1には属性1があり、データ2には属性2があり、・・・データnには属性nがある場合、ひとつのテーブルに属性1〜nを持たせるのは正規化されていないわけではないだろ。
それをパフォーマンスの問題なんかでテーブル分割を分割すると、めんどくさいことになる。
0131デフォルトの名無しさんNGNG
>>130
そのテーブルに疑問持ってないの？本当に？
おかしいと思わないの？
0132デフォルトの名無しさんNGNG
>>130
もう少し具体的に話してみて。それだけだと、

データID 属性種別 属性値

という形の表にできそうに見えるから。
0133デフォルトの名無しさんNGNG
>>123
それXMLスキーマとRDBのDMLで書いてみてよ。
本当にRDBの方が複雑って言えるか？
0134デフォルトの名無しさんNGNG
仕様が決まれば表現できるのはアタリマエのような・・・

変化に対する適応力の話に見えるなあ。
RDBって表を変えるのが相当大変じゃない？
0135デフォルトの名無しさんNGNG
>>134
ここまでかかってやっと本題だね。はっきりいってそこが一番の違いだと思うよ。
0136デフォルトの名無しさんNGNG
>>134
属性の追加、テーブルの追加で済む程度のものであればなんの
問題もないというのはガイシュツ。
もしデータモデルに大幅な変更があった場合、XMLなら変更が
簡単、なんてことはない。
0137デフォルトの名無しさんNGNG
>>132
属性の型が違ったら？
0138デフォルトの名無しさんNGNG
>>137
すべてtext型で解決。
0139デフォルトの名無しさんNGNG
>>138
まぜっかえすなﾊﾞｶﾔﾛｳｗ
0140デフォルトの名無しさんNGNG
>>137
その場合でも、XMLでできてRDBにできない変更というと、数値型の
属性を文字型にするとかくらいかな？

そんな変更するくらいなら、俺なら素直に属性追加するが。
0141デフォルトの名無しさんNGNG
「何の問題もない」といってるけど、実は・・・
0142デフォルトの名無しさんNGNG
ID XPATH VALUE

こんな表でXMLの真似事ができそうだな。

ID NAME TYPE CHAR_VAL INT_VAL DATE_VAL...

とかでバリアントの真似事....はさすがに嫌だな。
0143デフォルトの名無しさんNGNG
>>135
やっと本題って、データのモデルが違うから、RDBで表しやすいデータや、RDBで表しにくいけどXMLでは表しやすいデータがある、というのが本質なんだけど。
それをなんか、例えばであげたものの揚げ足をとって、RDBでも十分とか、話の本質を理解せずにツッコミいれてる奴がいて混乱させてるだけ。

結局、モデルのギャップを埋めることの大切さを理解してないという点では、ROマッピングの意味をわからずMAPでも同じことができるからROマッピングは必要ないといってたのと同じ。
0144デフォルトの名無しさんNGNG
それはまた別
0145デフォルトの名無しさんNGNG
>>143
そこんところをもちっと本質的に説明できる例を挙げてくれりゃ
他も納得するんだろうけど。簡単に揚げ足とられるような「例えばで
あげたもの」じゃなくてさ。

RDBで表現するよりXMLで表現するのに適したデータというのは
確かに存在する。たとえば既にXMLで表現されたデータそのものとか。
でもじゃなにも言っていないのとおなじこと。
一方で、RDBのテーブルに一対一で対応する形のデータ以外は
すべてリレーショナルモデルへの落とし込みが必要なわけで、その
意味では「めんどくさい」のも確か。
でもそれはRDB遣いにとっては常態であって、ことさら困難を言い
立てるものでもない。また、適切なモデルに落とし込む手間が必要と
いう意味ではXMLも同様。

そこまでの前提を置いた上で、XMLモデルで表現するのは容易だが
リレーショナルモデルで表現するのが困難なケースにどんなものが
あるかというところが問題なわけ。

要は上で挙げられた、RDBでは「間違ってもできない」「かなり表現
しづらい」「データの表現だけで大変な労力が必要」ってところの
揚げ足を取られない例を挙げて欲しいわけなんだが。
0146デフォルトの名無しさんNGNG
適しているかどうかはそりゃあるんじゃね？

それより、変化への対応の話をしたいんだが。

昔みたいに１年かけて作って７年そのまま稼動、みたいなことは
少なくなってきてるんだし。
0147デフォルトの名無しさんNGNG
>>146
そういう話がしたいってんなら自分でしろよ。
まず>>136に対してなにか言いたいことはないのか？
0148デフォルトの名無しさんNGNG
すぐに「適しているかどうか」の話に引き戻そうとするのがウザイ
と言ってるだけ。

RDB経験豊かな人に尋ねたいのは、対応しづらい仕様変更はあったか、
それをどのように対応したか、という経験談。

ただ、>>145みたいな
>でもそれはRDB遣いにとっては常態であって、ことさら困難を言い
>立てるものでもない。

みたいな寒い発言は勘弁していただきたい。
0149デフォルトの名無しさんNGNG
すぐに「今まで無かったから今後もいらないだろう」の話に引き戻そうとする方がウザイ
0150デフォルトの名無しさんNGNG
>>148
>すぐに「適しているかどうか」の話に引き戻そうとするのがウザイ

オレはXML-DBの使いどころの話をしてるから、それは当然だ。

>RDB経験豊かな人に尋ねたいのは、対応しづらい仕様変更はあったか、
>それをどのように対応したか、という経験談。

>>134の話を続けたいのかと思ったがどうも違うようだな。
他の香具師が乗ってくるよう手前で話を振らなきゃ、望み通りの
議論にならんのはアタリマエだろう。ワガママ言うなよ。
0151デフォルトの名無しさんNGNG
>>150
XML-DBの話はこちらへ。

データベース板　XML統合スレッド
http://pc5.2ch.net/test/read.cgi/db/1057207891/l50

情報システム板　XML-DBの今後！？
http://science3.2ch.net/test/read.cgi/infosys/1051815370/l50
0152デフォルトの名無しさんNGNG
Hibernateで、複数のJNDIを使い分けることは可能なのでしょうか？
テーブルＡ jdbc/hoge1ds
テーブルＢ jdbc/hoge2ds
0153デフォルトの名無しさんNGNG
RDBに、ツリー構造のデータを放り込む良い方法ないですか。
子が親へのポインタ持ってるだけだと、上から降りて検索するのが
SQLの繰り返し発行になってしまって非常に遅くて困るんですが。
0154デフォルトの名無しさんNGNG
ツリー１個に ID つけて
その ツリーID もってるレコード全部取り出したら
0155デフォルトの名無しさんNGNG
>>154
全部というわけではなくて、特定ノード以下だけ選択したかったり…
ID工夫するしかないかな？あるいは、親ノードIDと子ノードIDの対応表
だけ別に作るか…ｱﾀﾏｲﾃ。
0156デフォルトの名無しさんNGNG
>>155
汚い手ですが、ツリー上のノードを示す「パス」をカラムとして
持てばいいのでは。
正規化とは反対の方向になりますがね。
0157デフォルトの名無しさんNGNG
>>152
複数のセッション使えばいいんじゃない？
0158デフォルトの名無しさんNGNG
JDO実装一覧

* Exadel JDO (Riflexo) http://www.exadel.com
* FastObject (Versant) http://www.fastobjects.com
* FrontierSuite (ObjectFrontier) http://www.objectfrontier.com
* IntelliBO (Signsoft) http://www.intellibo.com
* JDO Toolkit (MVCSoft) http://www.mvcsoft.com
* JDOGenie (Versant) http://www.jdogenie.com
* JPOX http://www.jpox.org
* JRelay (Object Industries) http://www.objectindustries.com
* Kodo JDO (SolarMetric) http://www.solarmetric.com
* Lido (LIBeLIS) http://www.libelis.com
* ObjectDB (ObjectDB Software) http://www.objectdb.com
* ObjectStore (Progress Software) http://www.objectstore.net
* OJB (Apache) http://db.apache.org/ojb/
* Orient (Orient Technology) http://www.orientechnologies.com/
* PowerMap JDO (SCE) http://www.powermapjdo.com
* Speedo (ObjectWeb) http://speedo.objectweb.org
* TJDO http://tjdo.sourceforge.net
* XORM http://xorm.sourceforge.net
0159デフォルトの名無しさんNGNG
>>158
JDO も廃れたね〜。
0160デフォルトの名無しさんNGNG
結局なんだったのかなぁ
ORマッピングにこだわりすぎてROマッピングがやりにくかったとか？
0161デフォルトの名無しさんNGNG
>>153
「再帰SQL」でぐぐれ
今ならたいていのRDBMSで使えるだろ
0162デフォルトの名無しさんNGNG
>>161
実装してるのはDB2だけだと思ってたけど、他にもあったっけ?
0163デフォルトの名無しさんNGNG
JavaWorld9月号のCayenne特集に従ってソースコードを生成してみた。

package package1.auto;

import java.util.List;

/** Class _Actor was generated by Cayenne.
* It is probably a good idea to avoid changing this class manually,
* since it may be overwritten next time code is regenerated.
* If you need to make any customizations, please use subclass.
*/
public class _Actor extends org.objectstyle.cayenne.CayenneDataObject {

public static final String BIRTHDAY_PROPERTY = "birthday";
public static final String HOMETOWN_PROPERTY = "hometown";
public static final String NAME_PROPERTY = "name";
public static final String SEX_PROPERTY = "sex";
public static final String MOVIE_ARRAY_PROPERTY = "MovieArray";

public static final String ID_PK_COLUMN = "id";

public void setBirthday(java.util.Date birthday) {
writeProperty("birthday", birthday);
}
public java.util.Date getBirthday() {
return (java.util.Date)readProperty("birthday");
}


0164デフォルトの名無しさんNGNG
public void setHometown(String hometown) {
writeProperty("hometown", hometown);
}
public String getHometown() {
return (String)readProperty("hometown");
}


public void setName(String name) {
writeProperty("name", name);
}
public String getName() {
return (String)readProperty("name");
}


public void setSex(String sex) {
writeProperty("sex", sex);
}
public String getSex() {
return (String)readProperty("sex");
}

0165デフォルトの名無しさんNGNG

public void addToMovieArray(package1.Movie obj) {
addToManyTarget("MovieArray", obj, true);
}
public void removeFromMovieArray(package1.Movie obj) {
removeToManyTarget("MovieArray", obj, true);
}
public List getMovieArray() {
return (List)readProperty("MovieArray");
}


}
0166デフォルトの名無しさんNGNG
最新のベータ版を使っての
感想：

java.util.Listはimport文を生成しているのに
java.util.Dateと直接書いてるのが納得いかない。

同様に、package1.Mode objという書き方も納得いかない。
同じパッケージ内ならそんなもんいらんちゅーに。

_PROPERTYという名前の定数はどうにかならないのだろうか？

BIRTHDAY_PROPERTY という変数を使っているにもかかわらず"birthday"
という文字列を直に使うとはどういうことか？
0167デフォルトの名無しさんNGNG
>>166
java.sql.Date対策だろ
0168デフォルトの名無しさんNGNG
>>162

Oracleでは階層問い合わせだな。

SQL ServerではYukonから使える模様。
0169デフォルトの名無しさんNGNG
>>167
Generation Gapパターンが使われているんだし
java.sql.Date使われていないんだったらimport宣言してもええじゃん
と激しく思うんだが。
0170デフォルトの名無しさんNGNG
>>169
なんかの拍子にimport java.sql.*ってやったらエラーになるからじゃないの？
0171デフォルトの名無しさんNGNG
import使わずにフルパッケージ指定してくれればベストか。
0172デフォルトの名無しさんNGNG
>>170
いまどきimportに*を使う香具師はDQN
0173デフォルトの名無しさんNGNG
と、条件が限定されるローカルルールを押し付ける奴もDQN
0174デフォルトの名無しさんNGNG
と、自分の主観を押しつけるヤツもDQN
漏れﾓﾅｰ
0175デフォルトの名無しさんNGNG
iBATISは「イーバティス」と読む
http://d.hatena.ne.jp/kagamih/20040822#p4

@IT Hibernateで理解するO/Rマッピング:簡単なプログラムでO/Rマッピングを体験
http://www.atmarkit.co.jp/fjava/rensai3/ormap04/ormap04_1.html
0176デフォルトの名無しさんNGNG
俺もあいばてぃすって呼んでた。やっぱiMODEとかiMACの影響だな。
0177デフォルトの名無しさんNGNG
Hibernateでコネクションプールってどうしてる？
アプリケーションサーバーのDataSource使ってる？
HibernateからDBCP　or　c3p0？
MySql3.xだと、c3p0でごみセッションがのこりやがる。

DataSource使いたいけど、うまくいかね。
この辺のドキュメントってどこかに纏まってないかな。
0178デフォルトの名無しさんNGNG
WEB+DBの最新号読んだが。
SeaserDAOってどうなん？
0179デフォルトの名無しさんNGNG
>>178
> WEB+DBの最新号読んだが。
> SeaserDAOってどうなん？

君の感想は？
0180デフォルトの名無しさんNGNG
>>178
ｻｸｰｼｬの日記。この URL 6月ころから部分からだけど
このへんから読み進めると S2Dao の概念がよく分かる。
[はてなダイアリー - ひがやすをのここだけの話]
http://d.hatena.ne.jp/higayasuo/searchdiary?of=30&word=S2Dao

公式ドキュメント
[Seasar - DI Container with AOP -]
http://homepage3.nifty.com/seasar/s2dao.html

スレ
[国産オープンソースDIコンテナSeasar V2(S2)]
http://pc5.2ch.net/test/read.cgi/tech/1092044210/

俺的にはかなりいいとおも。DAOインタフェースだけ書けば実行できるのは
かなりうれしい。Hibernate や DBUtils のいいとこどり。
ただ、今はまだｻｸｰｼｬにとっての完成系でないような気がするので
将来的に期待大。
0181デフォルトの名無しさんNGNG
>>179
そういう君の感想は？

サンプルプログラムにコメントが全然ないのが笑った。
Seasarの人たちって「美しいソース書けばコメントなんか不要」というポリシーなんだろうか。
0182デフォルトの名無しさんNGNG
>>181
あんなシンプルなソースにコメントいるか？
まー、人それぞれだけどな。
■ このスレッドは過去ログ倉庫に格納されています