ORマッピングはいらない
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2006/06/22(木) 11:55:30SQL直書きがいいに決まってる。
0002デフォルトの名無しさん
2006/06/22(木) 12:03:52複雑なSQLに対処できないし、
簡単なSQLならORマッピング使うまでも無い。
パフォーマンスを考慮したら、邪魔になること間違いない。
コードなかなくても、定義ファイルを作らなきゃいけないから
結局、何も楽にならないし。
データベースのフィールドの値を変数に代入する、
またはその逆の関数程度があれば十分。
0003デフォルトの名無しさん
2006/06/22(木) 15:30:380004デフォルトの名無しさん
2006/06/22(木) 16:54:532. DBの存在を意識せず、オブジェクトのことだけ考えればいい。
けど現実には>>2が言ってるみたいなことになったりもする。
俺自身はORマッパの是非は要件と使い方によると思うので、いるともいらないとも断言できない。
0005デフォルトの名無しさん
2006/06/22(木) 17:34:420006デフォルトの名無しさん
2006/06/22(木) 17:35:120007デフォルトの名無しさん
2006/06/22(木) 17:43:56ちょっと複雑なJOINには対応していないことが多い。
複雑なSQLかかないのなら、直で書いても手間じゃない。
0008デフォルトの名無しさん
2006/06/22(木) 23:59:45中で何やってるか丸わかりで安心だし、
SQL直接指定できて、検索結果はBeanで返ってくる。
コンバータ書けばO-R任意のマッピングもできる。
ただ、リフレクション使うから遅い。
大規模やパフォーマンスにシビアなシステムでは使えない。
0009デフォルトの名無しさん
2006/06/23(金) 00:44:49本格的にオブジェクトにしてくれよ。
たとえば継承やメソッドまで使えるようにする。
0010デフォルトの名無しさん
2006/06/23(金) 00:57:34何を言いたいのか。わけわからん。
0011デフォルトの名無しさん
2006/06/23(金) 01:01:42最近はDIと絡めて、色々自動生成したりリフレクションに頼ったりしてるが、
トランザクションの最初と最後を強制的に決めてしまう
クロージャや内部クラスのような使い方さえ躾けとけばいいと思う。
0012デフォルトの名無しさん
2006/06/23(金) 01:37:45分かって無いって感じだな。
0013デフォルトの名無しさん
2006/06/23(金) 09:48:14マッパー使って
帳票とかはSQL書きたい。
てなことでS2Daoがしっくりきた。
0014デフォルトの名無しさん
2006/06/24(土) 14:29:200015デフォルトの名無しさん
2006/06/24(土) 14:31:55というか、複雑なSQLが書きたい場面って、あんまり多くないとおもうのだがどうよ？
８割９割は簡単なSQLですんで、１割くらいはちょっと複雑になることがある。
それを考えると、すべてをSQL直書きは面倒くさい。
ORマッパーで楽できるところは楽して、SQL手書きでがしがしやりたいところは手書きでやるのがいちばん。
0016デフォルトの名無しさん
2006/06/24(土) 15:14:17ORマッピングするわけだが、
どういうこっちゃ？
はぁ？
0017デフォルトの名無しさん
2006/06/24(土) 15:30:12フィールドが200～300あるのを毎回打ち込むのマンドクセ
0018デフォルトの名無しさん
2006/06/24(土) 15:55:34思うのは俺だけか？
0019デフォルトの名無しさん
2006/06/24(土) 15:56:37×: フィールドが三桁も
○: フィールドの個数が三桁も
0020デフォルトの名無しさん
2006/06/24(土) 15:58:352～3って読んどいて
0021デフォルトの名無しさん
2006/06/24(土) 16:04:50JDBCのコネクションオブジェクト取れるしね。
ってことは、Hibernate使うときは素のSQL書かせないようには
当然してないと。
Mapに詰めるのは、メンバーが合意してるんだったらいいんじゃね？
って思う。漏れはHibernate使う人だから進んでは合意しない。
getter,setterがあると、eclipseでコード補完効くから、楽だしな。
あと、オブジェクト指向かDB指向かと言われたら、間違いなくDB指向だ。
まあHibernateのObjectの永続化の考えに反するかもしれないが、
RDBには、RDBなりの設計が重要だと考えてるから。
いつなんどき、変態DB屋が現れるかわからんしなｗ
0022デフォルトの名無しさん
2006/06/24(土) 16:09:25オブジェクトを使う以上は、フルSQLであろうとなんだろうと、
何らかのORマッピングをやってるわけで、
>>1 の言ってる話は、
なんらかのORマッピングフレームワークによる（半）自動化が、
必要かどうか、という話なんでないの？
0023デフォルトの名無しさん
2006/06/24(土) 16:25:150024デフォルトの名無しさん
2006/06/24(土) 16:29:34∧∧
(,,ﾟДﾟ)
/ |
～ＯＵＵつ
0025デフォルトの名無しさん
2006/06/24(土) 16:58:17結局どっちも遅いな
0026デフォルトの名無しさん
2006/06/24(土) 17:44:36それがORマッピングと何か関係が？
0027デフォルトの名無しさん
2006/06/26(月) 13:26:32>複雑なSQLが書きたい場面って、あんまり多くないとおもうのだがどうよ？
そっかなー、帳票にしろ、更新にしろ単純なSQLはあんまり無いけどなー。
特に更新系のSQLは WHERE を見れば仕様が分かるから
ORマッピング使ってダラダラ書かれると後からおっかけにくい。。
0028デフォルトの名無しさん
2006/06/27(火) 13:04:08たしかにパフォーマンス考えるとそっちがいいに決まってるんだけど、
パフォーマンス的にシビアでない場合なら簡単なSQLを数回発行するほうが
プログラムが簡単になる。
0029デフォルトの名無しさん
2006/06/27(火) 15:05:42SET 請求フラグ = 1
WHERE 売上日 = NOW
みたいなのは
if (obj.UriageDate == Now) {
obj.SeikyuFlag = 1;
}
これを対象件数分繰り返すの？
0030デフォルトの名無しさん
2006/06/27(火) 15:47:19dao.set請求フラグofToday( 1 );
みたいな感じジャマイカ
0031デフォルトの名無しさん
2006/06/27(火) 17:23:540032デフォルトの名無しさん
2006/06/27(火) 19:02:08対応するインスタンスの状態が変わる→任意のタイミングでDBに反映
って感じかな？俺は元はDB屋なんだけど、ORマッピングに関しては、オブジェクト寄り。
上に出てる多量の行を一気に更新する、ってのはORマッピングに対する反論としてよく出るけど、
オブジェクト（クラス・インスタンス）のほうから設計をすると、そういうのは例外ケースなわけ。
だからSQL直書きでもいいし、ストアドキックでもいいと思ってる。その間、インスタンスは使いづらく
なるけどね。
0033デフォルトの名無しさん
2006/06/27(火) 21:21:42空気嫁って？
0034デフォルトの名無しさん
2006/06/28(水) 00:17:570035デフォルトの名無しさん
2006/06/28(水) 00:52:53/つ_,∧ 〈（ ﾟдﾟ）
|（ ﾟдﾟ） ヽ ⊂ニ) エェ ── ｯ !?
ヽ__と/￣￣￣/ |
￣＼/＿＿＿/￣￣
0036デフォルトの名無しさん
2006/06/28(水) 10:02:49多分、InnoDB指定しないで「使えねぇ」って言ってるアホと思われ
0037デフォルトの名無しさん
2006/06/28(水) 15:51:25まじで？？
0038デフォルトの名無しさん
2006/06/28(水) 19:29:49仕事では「オブジェクト（クラス・インスタンス）のほうから設計」するのが
まず例外ケースだと思うけどね。
0039デフォルトの名無しさん
2006/06/28(水) 19:32:11SQLとORマッピングの比較じゃなくて、プレーンなファイルを使った場合とDB使った場合での
オブジェクトの永続化のやりやすさ、ってとこを考えないといけない
004032
2006/06/28(水) 19:38:46たまたま見たのでレス。
マジだよ。ただ、前提条件があるんだが、そこには触れていなかった。
・多量データの更新というのは、データをひとかたまりに見ていれば当然でてくるだろうけど。
多数のインスタンスという観点で見れば、それに一緒くたに変更をかけるのは、何か間違っ
てるでしょ？データベースなしと考えてみて。そういうクラス設計には絶対にしないはず。
する人は、無意識に「データベース」が頭にあるんだと思う。
・で、メンテナンス以外での一括更新ですが、これは単純にはあるクラスで集約するという
概念になります。データへの変更はなし、ただし特定クラスのインスタンスで集約されている
状態になる。
・集計などは夜間バッチで集計表に移したり、ストアドプロシージャを利用します。
得られた結果は元の表とは別のオブジェクトと考えればいい。
抽象的過ぎて、非現実的と思われるでしょうが、データベースにアクセスするんじゃなくて、
あくまでもインスタンスを永続的にストレージに保持する必要があって、たまたまデータベースを
利用するに過ぎないって観点です。そしてデータベースの中で済む処理はすべてお任せ。
上にも書いたけど、クラス・オブジェクト設計して、多量のインスタンスを変更するなんて、
お粗末な設計でしょ。一括ってことは、そこに関連性と法則性があるんだから。
って、いっぱい反論あるんだろうな…繰り返しになりますが、自分はSQL直書きでもストアドでもいいって
立場です。むしろそうやることでドメインモデルから距離を置いたほうがいいよねーって感じ。
0041デフォルトの名無しさん
2006/06/28(水) 20:14:02UPDATE 売上
SET 請求フラグ = 1
WHERE 売上日 = NOW
みたいのは、「請求（乃至イベント）」クラスに1レコード当日日付持たす、でいいわ
日別状態クラスの当日ステータス更新ってかたちでもいい
0042デフォルトの名無しさん
2006/06/29(木) 10:46:330043デフォルトの名無しさん
2006/06/29(木) 17:43:38メモリ上の各レコードのインスタンスとの整合性保持するのが困難
0044デフォルトの名無しさん
2006/06/29(木) 19:17:290045デフォルトの名無しさん
2006/06/29(木) 22:37:48帳票とかのデータ構造が先に来るってのは、
DB屋の設計手法としても間違ってると思うのだが。
Sヨお得意の画面/帳票まんまな糞DBじゃんｗ
0046デフォルトの名無しさん
2006/06/30(金) 01:59:280047デフォルトの名無しさん
2006/07/01(土) 21:58:23>これを対象件数分繰り返すの？
ORマッピングだけをつかうなら、そういうことになる。
あとはdeleteのときも、件数分delete文を発行する。
もちろんこれは効率が悪いけど、それで速度的に問題ない場面ならORマッピングをそのまま使う。
問題ある場合だけSQLをがしがし書く。
だからORマッピングだけで完結させるのは難しいし、そんなことにはこだわらないほうがいい。
>>40
>多数のインスタンスという観点で見れば、それに一緒くたに変更をかけるのは、何か間違っ
>てるでしょ？データベースなしと考えてみて。そういうクラス設計には絶対にしないはず。
そんなばかな。業務システムではしょっちゅうあるけど。なぜこんなことを言い切れるのか不思議。
0048デフォルトの名無しさん
2006/07/02(日) 09:55:24セッションやらキャッシュやら自動トランザクションやら訳判らんし、データ更新してもTomcat再起動すると元に戻ってたりと、
ORマッパーが裏で何やっているか完全に把握している人間がいないとダメだわ
まぁ俺が不勉強なだけだけど、
普通にJDBC直書きでトランザクション制御はTemplateMethodパターンの方が遥かにわかりやすかった
0049デフォルトの名無しさん
2006/07/02(日) 10:21:17自分でわかってんじゃん。
新しい物を覚える能力に欠けていると自覚するなら
この業界でやっていくのは難しいよ。
オブジェクト指向が理解できないCOBOLオヤジと一緒。
早く別の道を探した方が良さそうだね。
0050デフォルトの名無しさん
2006/07/02(日) 10:38:46そんなあなたにS2DAOをお勧めする
設定ファイルもシンプルで簡単だし、サンプルもわかりやすくてマジ最高
0051デフォルトの名無しさん
2006/07/02(日) 11:33:460052デフォルトの名無しさん
2006/07/02(日) 14:04:16でとってきた奴はO/Rマッピングオブジェクトに入れた方が
その後ガシャガシャやるのに便利じゃないか。
ただHibernateみたいにupdateでO/Rマッピングオブジェクト渡して
全カラムupdateするのは嫌だな。
うっかり変更する必要がないプロパティ変更しちゃってたら大変だ。
なのでupdateは、必要なカラムだけupdateするSQL呼び出しをDAOを作る。
0053デフォルトの名無しさん
2006/07/02(日) 14:14:27＞ただHibernateみたいにupdateでO/Rマッピングオブジェクト渡して
＞全カラムupdateするのは嫌だな。
無知。使いこなせていない奴が文句言うな。
0054デフォルトの名無しさん
2006/07/02(日) 14:28:56一生懸命勉強しないと使いこなせないものってダメだと思う、Hibernateがそうなのかどうかは
別として。
0055デフォルトの名無しさん
2006/07/02(日) 14:34:44ダメなものかどうかを自分で決められるのなら、そう言ってろ。
おまい自身が「一生懸命勉強しないと」と感じるかどうかが基準か？
ダメだどうのと言っている奴がダメだ。
この仕事をしている限り、デファクトスタンダードは避けて通れないんだよ。
0056デフォルトの名無しさん
2006/07/02(日) 14:39:090057デフォルトの名無しさん
2006/07/02(日) 14:45:19「SQL記述の冗長な部分のみを自動化する」機能であって
システムとしてはよりDBに依存した形になる。
DBの存在を隠蔽するとか、SQL的な記述を隠蔽するとかいう説明は誤り
作成されるSQLを完全に理解できるくらいでないと、O/Rマッパーを使うのは難しい
SELECT文でカラムをJOINしたテーブル毎に全部書いたり、結合の度にJOIN句を書いたり
INSERTやUPDATEを書く処理は、どれもテーブル定義さえ知っていたら自動化できる処理だから
そこら辺はO/Rマッパーに任せる。
逆に検索条件や副問い合わせを駆使するようなSELECT文は、SQLだからこその機能だからSQL寄りに書く。
Hibernateなら、HQLを使えばSQLとほぼ同レベルのことが書ける。
HQLではFROM句での副問い合わせやUNIONが書けないのは不満だが、そんなときはSQLQueryを使えばいい
005854
2006/07/02(日) 16:16:29いやー、おまいみたいな優秀な奴だけを集めてプロジェクトを進めるのが難しいという現実がある以上、
一生懸命勉強しなくても使えるものを採用しないとダメだと思うけどねぇ。
ダメだどうのと言っている奴がダメなのは同意するけど、だからといってそういう奴でも
開発メンバーに加えざるをえない状況もあるわけで。
ところでHibernateはO/Rマッピングのデファクトとまでいっちゃっていいものなんですかね？
0059デフォルトの名無しさん
2006/07/02(日) 16:35:10>>55が優秀かどうかもわからないのに、口だけ調子いいこと言ってる奴もダメだな。
メンバー全員がHibernateに精通していないと、という前提になっているところもダメ。
設計やフレームワークの使い方を間違っている可能性大。
0060デフォルトの名無しさん
2006/07/02(日) 19:31:55一人だけ詳しい奴がいれば、あとの連中の生産性を最大化することが
できる。
むしろそれがORMの最大の狙いで、SQLを使ったやり方だと、メンバー
全員がDB設計SQL設計に精通している必要が出てくる。
0061デフォルトの名無しさん
2006/07/02(日) 21:11:10「優秀かどうかもわからないのに、口だけ調子いいこと言ってる」
ただのイヤミだろ。
「メンバー全員がHibernateに精通していないと」という前提をしてないからこそ
「一生懸命勉強しないと使いこなせないものってダメだと思う」という書き込みがあるわけだが。
0062デフォルトの名無しさん
2006/07/02(日) 21:26:59＞「メンバー全員がHibernateに精通していないと」という前提をしてないからこそ
＞「一生懸命勉強しないと使いこなせないものってダメだと思う」という書き込みがあるわけだが。
矛盾してないか？
メンバー全員がHibernateに精通していることが前提でなければ、
メンバーの一部に使いこなせる奴がいれば充分だろ？
メンバー全員が>>55みたいに優秀な奴である必要はないんだよ。
0063デフォルトの名無しさん
2006/07/03(月) 00:27:250064デフォルトの名無しさん
2006/07/03(月) 00:32:200065デフォルトの名無しさん
2006/07/04(火) 13:24:50>>52
>select * from table
こんなのばっかりなのか？
0066デフォルトの名無しさん
2006/07/05(水) 01:13:270067デフォルトの名無しさん
2006/07/08(土) 01:01:09理解している奴は少ない。
シンプルに実装しました、とかベタで書きましたとかいって
for文の5段ネストとかそんな感じのソースが出てくる。
0068デフォルトの名無しさん
2006/07/08(土) 16:41:11楽するためにプログラミングしてるはずなのに、全然楽じゃない。
XMLなんて醜くて遅くなるだけだし。
一人の詳しい香具師が居ればいいってのもいまいち。
その一人が逃亡した時点で終わるし、その一人の給料だけ高くすると不満が出るし、他がやる気無くすし、その一人のために他の香具師が低い賃金でこき使われることに成る。
詳しくなくても簡単に使えるORマッパが求められてると思う。
0069デフォルトの名無しさん
2006/07/08(土) 16:52:19使ってみたORマッパーとその問題点を具体的にきぼん。
> XMLなんて醜くて遅くなるだけだし。
だけでは根拠が弱い（XMLを使うと遅くなるわけではないので）。
0070デフォルトの名無しさん
2006/07/08(土) 17:32:220071デフォルトの名無しさん
2006/07/08(土) 17:38:47この辺りは使ったことないけど、どうなんだろう？
0072デフォルトの名無しさん
2006/07/08(土) 20:40:120073デフォルトの名無しさん
2006/07/08(土) 20:45:29実装速度じゃなくて開発効率の話しかな？
マッピングファイルを手書きしていたらORMのメリットはかなり低下するだろうな。
ここは、現実的にはMiddlegenとかXDocletを使って自動生成する部分だろう。
手書きめんどくさいと言っている人は雑誌やWebのサンプルに沿って
ちょっとモノを作ってみただけで判断してないか？
>>68 はフレームワークの使い方やプロジェクトでの役割分担を根本的にわかっていない希ガス
0074デフォルトの名無しさん
2006/07/10(月) 00:39:47問いたい。
0075デフォルトの名無しさん
2006/07/11(火) 23:41:51いっつも
http://(domain)/hogehoge/mogemoge.jpg
↑の意味のドメインが頭に浮かんできて、何の事やらサッパリわからんくなる。
0076デフォルトの名無しさん
2006/07/12(水) 06:39:49↑これ自体間違いだしな
0077デフォルトの名無しさん
2006/07/14(金) 01:15:070078デフォルトの名無しさん
2006/07/14(金) 13:39:42↑これ自体間違いだしな
0079デフォルトの名無しさん
2006/07/14(金) 22:38:17mailto:sage@(domain)
ってのは？
0080デフォルトの名無しさん
2006/07/15(土) 09:25:47どうなんだよ、オラオラ
0081デフォルトの名無しさん
2006/07/15(土) 09:35:52については、間違いだとは判るが
http:// 自体のどこが間違っているのかは俺には判らん。
http://www.yahoo.co.jp/ の場合、
インターネットドメインは yahoo.co.jp であって www.yahoo.co.jp ではない。
http://203.216.247.249/ だったらインターネットドメインはどこにも含まれない。
0082デフォルトの名無しさん
2006/07/15(土) 09:36:440083デフォルトの名無しさん
2006/07/15(土) 09:50:550084デフォルトの名無しさん
2006/07/15(土) 11:01:55(host)からwww1とかwwwとか、ftpを取り除けば(domain)になるってことだな。
で、結局、ドメインモデルと(domain)では、ドメインって別のものを指してるよな？
そこら辺がおれにはよく分からんのだよ。
では、そこを起点に議論の再開を求む。
0085デフォルトの名無しさん
2006/07/15(土) 11:15:15代数的かつ整合完備な半順序集合bcdomだろう。
bcdomは関数構成子に関して閉じており、圏としてみた場合
cccをなす
0086デフォルトの名無しさん
2006/07/15(土) 11:32:59DNS におけるドメインというのは、ネットワークにおける（管理上）の「領域」、
企業や部門などの管理者が置かれる単位。
データモデリングにおけるドメインは、データにおける「領域」、
つまり、対象領域とする業務やアプリケーションに含まれる（モデル化すべき）
データの集合、ないし、データが存在する対象領域そのもの。
0087デフォルトの名無しさん
2006/07/17(月) 04:05:39考えてみようって話だな。
カタカナでドメインだと確かに
この業界、初学者にはまぎらわしいですな。
008887
2006/07/17(月) 04:22:52どうも物理的な場所のイメージが強くてよくわからん。
「問題領域」なんて訳がよく使われるけど、
なんか頑張って考えたのが伝わってきちゃっていかん。
「うちはA社とはドメインが違うから競合しません」
みたいな言い方もよく聞く。
そうすると、「業界」みたいな意味もあるように思える。
正確には粒度はもっと小さいんだろうけど。
てことは、ドメインモデルって
「業界用語」って事でいいんじゃないの？
ただの業界用語集ってだけでなく、
構造まで表現したもの、てなかんじ。
寝ようと思って布団に入ったら思いついたから
また書いた。
0089デフォルトの名無しさん
2006/07/17(月) 10:17:570090デフォルトの名無しさん
2006/07/17(月) 10:40:47ちがうだろ。
009187
2006/07/17(月) 16:46:270092デフォルトの名無しさん
2006/07/17(月) 17:31:01ドメインという言葉よりモデルの中身の方が大事だよね
0093デフォルトの名無しさん
2006/07/18(火) 13:57:230094デフォルトの名無しさん
2006/07/18(火) 15:38:560095デフォルトの名無しさん
2006/07/18(火) 23:36:57もちょっとふんばってイドメ
0096デフォルトの名無しさん
2006/07/18(火) 23:42:040097デフォルトの名無しさん
2006/07/19(水) 02:17:550098デフォルトの名無しさん
2006/07/19(水) 10:27:12これがトドメだな
0099デフォルトの名無しさん
2006/07/19(水) 11:10:260100デフォルトの名無しさん
2006/07/28(金) 19:08:27O/Rマッピングに妙に肩入れしてるのはJAVA界隈の人だけだと言うことは分かった。
0101デフォルトの名無しさん
2006/07/29(土) 14:29:49SELECT 文の出力を、変数に代入するコードを書くことを
「あたりまえ」
だと思って何の不満も感じてないなら、 OR マッピングなんて必要ないわな。
0102デフォルトの名無しさん
2006/07/29(土) 22:45:35SELECT文の出力を変数に代入するコードを書かなくてもいい代わりに、
SELECT文の出力を変数に代入する設定ファイルを書かなくてはいけない。
本質的には何も変わらない。
0103デフォルトの名無しさん
2006/07/29(土) 22:57:44設定ファイルを手書きするバカなんていないけどな。
0104デフォルトの名無しさん
2006/07/29(土) 23:11:59end
で完了だけどな
0105デフォルトの名無しさん
2006/07/31(月) 09:45:01それと同等のSQLを吐くプログラムコードを見せて欲しい。
>>101でもいいよ。
0106デフォルトの名無しさん
2006/07/31(月) 09:59:250107デフォルトの名無しさん
2006/07/31(月) 10:48:49ORMがさらっとやってくれるCacheとLazyLoadingの方が
パフォーマンス上がる場合が多いよ。
自力でCacheしろという意見はきかん。
0108デフォルトの名無しさん
2006/07/31(月) 13:34:07>SELECT 文の出力を、変数に代入するコードを書くことを
そんなことしないってｗ
0109デフォルトの名無しさん
2006/07/31(月) 15:24:39お前がそうしないのは勝手だが
お前の事情など知った事ではない。
0110デフォルトの名無しさん
2006/07/31(月) 15:34:20ないんじゃないのか? API直接叩くなら別だけど。
>>101がどういうつもりで言ってるのか知らないけど。
0111デフォルトの名無しさん
2006/07/31(月) 21:01:13どうやってSQL以外のプログラムからDBにアクセスするんだ。
0112デフォルトの名無しさん
2006/07/31(月) 23:08:40変数に入れないって事は
M a p に 入 れ る
って事じゃないか。
0113デフォルトの名無しさん
2006/07/31(月) 23:18:460114デフォルトの名無しさん
2006/07/31(月) 23:21:44おおー久々のネタだ！！！
よく覚えてたなｗ
0115デフォルトの名無しさん
2006/08/01(火) 14:05:45直接レコードセットのフィールド参照すりゃいいじゃん
0116デフォルトの名無しさん
2006/08/02(水) 00:24:50だよな。
0117デフォルトの名無しさん
2006/08/03(木) 15:10:140118デフォルトの名無しさん
2006/08/03(木) 15:21:03それとも Javaで言うと ResultSet をViewから直接参照するのか？
非常識な設計だな。
0119デフォルトの名無しさん
2006/08/03(木) 17:49:55>それはORMとどう違うのだ？
0120デフォルトの名無しさん
2006/08/03(木) 19:27:19そのコードを、作成するたび、変更があるたび、
いちいち人間さまが書く必要があるかないか。
0121デフォルトの名無しさん
2006/08/03(木) 19:47:01つまり、ViewでResultSetを直接参照してるってこと？
データをオブジェクトとして扱うという発想がないってこと？
.NETってWebでもそんなことするの？
0122デフォルトの名無しさん
2006/08/03(木) 19:53:34っていうか、なんでそこでView がでてくるのかわけがわからん。
仮にいちいち書くとしても、データアクセス層の話だぞ。
0123デフォルトの名無しさん
2006/08/03(木) 19:59:47ん？じゃあ、最終的にはどこかで取り出したデータを
オブジェクトに入れ替えるコードは書くわけ？
0124デフォルトの名無しさん
2006/08/03(木) 20:04:41>取り出したデータをオブジェクトに入れ替える
だから、それがORマッパの機能で、それ（ORマッパ）を使わない場合は、
そのコードを人間がいちいち手で書くことになる、
というのが、>>120 の文意だよ。
0125デフォルトの名無しさん
2006/08/03(木) 20:12:13ああ、そういうことね。>>120 を読み違えてた。
ResultSetを直接扱えば、変更があってもマッピング定義を
変えなくていいじゃん、という非常識な意見だと思ったよ。
じゃあ、結局ORMｲﾗﾈって言ってるやつは
いちいち手書きしてるってことか。
なんと非効率なことか・・・・
アホか。
0126デフォルトの名無しさん
2006/08/03(木) 23:12:320127デフォルトの名無しさん
2006/08/04(金) 11:49:37なにを？
0128デフォルトの名無しさん
2006/08/04(金) 12:23:000129デフォルトの名無しさん
2006/08/04(金) 17:15:53片が付く議論なのに、なんで出してくれないの?
0130デフォルトの名無しさん
2006/08/04(金) 17:29:50そもそも前提が間違ってるから。
今時おまいみたいなこと言う奴まだいるんだなｗ
0131デフォルトの名無しさん
2006/08/04(金) 17:31:44で、例は? また出さずにグダグダやるわけ?
0132デフォルトの名無しさん
2006/08/04(金) 17:48:35どうしても何を言われてもオブジェクト指向を理解できないｺﾎﾞﾗｰのように頭ガチガチなんだなｗ
0133デフォルトの名無しさん
2006/08/04(金) 18:19:280134デフォルトの名無しさん
2006/08/04(金) 18:31:11前提とかその辺はどうでもいいのよ。
オブジェクト指向はかくあるべき云々なんて教条的で頭ガチガチ(笑)な話じゃなくて
単純にO/Rマッピングの利点の話。
単にオブジェクト指向ってだけならデータセットレベルでもオブジェクト指向してるワケで
O/Rマッピングを採用することでどんな具合に楽になるの? ってことが知りたいわけ。
だから>>105に挙げた例を出してくれって言ってる。
0135デフォルトの名無しさん
2006/08/04(金) 18:46:28＞オブジェクト指向はかくあるべき云々なんて教条的で頭ガチガチ(笑)な話じゃなくて
ホントにわかってないなｗ
そんな話をしてるんじゃないだろ？
オブジェクトを永続化するのになぜ>>105のような例が出てくるのかまったく理解できない。
0136デフォルトの名無しさん
2006/08/04(金) 18:48:54そんな奴が無理矢理使っても失敗するからやめとけ。
0137デフォルトの名無しさん
2006/08/04(金) 19:18:13オブジェクトの永続化なんて言っても、その永続化の先にあるのはあくまで
SQL完備のRDBMSが前提でしょ?
>>105の何がおかしいわけ?
0138デフォルトの名無しさん
2006/08/04(金) 19:32:131. 関連するtableの全recordをobjectにmapping
2. 1で生成したobjectの集合に対して、好きな方法で必要なobjectを抽出する
0139デフォルトの名無しさん
2006/08/04(金) 20:04:38どうしたら>>105みたいな状況になるんだかｗ
設計とモデリングがヤバいだろ。
0140デフォルトの名無しさん
2006/08/04(金) 20:27:46ORMの利点と欠点を説明すれば納得するはずだ。
そもそもはオブジェクトの世界とデータレコードの世界の
インピーダンスミスマッチの解消のための技術。
そのため、相互マッピングというオーバーヘッドが発生するのは
デメリットといえる。
しかしその代わり、オブジェクトの世界における取り扱いの
柔軟性というメリットを享受できる。
その点に魅力を感じないのであれば、その人にはORMは必要なし。
0141デフォルトの名無しさん
2006/08/04(金) 20:38:42関連テーブルにレコードが100万個あったら100万個オブジェクトを作るのか？
最悪だな。
0142デフォルトの名無しさん
2006/08/04(金) 20:46:10そんなわけないだろ。アホか。
Lazy Loading ってのがあるんだよ。
0143デフォルトの名無しさん
2006/08/04(金) 20:49:320144デフォルトの名無しさん
2006/08/04(金) 20:54:27ORM使うのが目的じゃないし、ただの手段にこだわってもな。。
0145デフォルトの名無しさん
2006/08/04(金) 21:10:00正解。
0146デフォルトの名無しさん
2006/08/04(金) 21:59:39げー、なにそれ。
裏でSQL作って投げるんじゃなくて、全レコード引っ張ってきて自前で総当たりするのか…。
そういう代物だとは思わなかった。
0147デフォルトの名無しさん
2006/08/04(金) 22:10:320148デフォルトの名無しさん
2006/08/04(金) 22:37:11オートマ市販車で、ワークスマシンと同等のタイムを出してみろ。
といっているのと変わらん。無意味な質問だ。
0149デフォルトの名無しさん
2006/08/04(金) 22:57:43誰も実行速度の話なんてしてないじゃん。
0150デフォルトの名無しさん
2006/08/04(金) 23:24:33ORMがそんなに便利になれるわけない
0151デフォルトの名無しさん
2006/08/04(金) 23:59:52うん、君を除いては「誰も」していないね。
0152デフォルトの名無しさん
2006/08/05(土) 01:21:56JPQLがそれら全てに対応してることからわかるように
検索処理はSQL的な記述を最大限に利用するのが正解
O/Rマッピングが力を発揮するのは、データを取得した後の登録・更新処理
Hibernateの場合、Beanに値をつめてツールのメソッドにわたせばINSERT文が発行されるし
SELECT文で取得したBeanの値を変更すれば、トランザクション終了時に自動的にUPDATE文が発行される。
これらのINERT・UPDATE文はJDBCのバッチUPDATEを利用する為、ある程度のパフォーマンスも期待できる。
また、このとき排他処理が自動的に実行される。
Webアプリなどのロングトランザクション管理が必要な場合は必須といえるツールだと思う
データのBeanへのマッピングも便利だが、それは昔からDbUtilsなどで実現していた機能だからな
>>143
ツールで自動作成すればいい。外部キー制約をつけていれば、クラス間の関連定義まで自動でやってくれる
0153デフォルトの名無しさん
2006/08/05(土) 23:28:02自動化出来ないのか？
0154デフォルトの名無しさん
2006/08/06(日) 02:28:23できるよ
ってか、するのが当然・普通・あたりまえ。
0155デフォルトの名無しさん
2006/08/06(日) 02:35:34ここにいる人達は正直ｲﾀｲと思った。
まずは日本語をｗ
0156デフォルトの名無しさん
2006/08/06(日) 09:51:560157デフォルトの名無しさん
2006/08/06(日) 10:41:30自動化出来ないのか？
0158デフォルトの名無しさん
2006/08/06(日) 10:44:04できるよ
ってか、するのが人として当然・普通・あたりまえ。
0159デフォルトの名無しさん
2006/08/06(日) 10:52:37あっても、逆に手間がかかる。
0160デフォルトの名無しさん
2006/08/06(日) 13:09:240161デフォルトの名無しさん
2006/08/06(日) 13:15:40シッタカ乙。
ORMの役割・メリットはそこじゃないっつーの。
0162デフォルトの名無しさん
2006/08/06(日) 14:29:52PG云々以前の問題だなｗ
0163デフォルトの名無しさん
2006/08/06(日) 17:01:51> ORMの役割・メリットはそこじゃないっつーの。
じゃあどこさ？
0164デフォルトの名無しさん
2006/08/06(日) 17:16:190165デフォルトの名無しさん
2006/08/06(日) 18:11:45ソースで会話したほうが速いことが多杉！
0166デフォルトの名無しさん
2006/08/06(日) 19:27:070167デフォルトの名無しさん
2006/08/06(日) 20:13:48SQLを知ってる・知らないではなく、
SQLとオブジェクトのマッピング作業をフレームワークがやってくれる点。
0168デフォルトの名無しさん
2006/08/06(日) 23:34:16ORMはSQLを知っていることが利用の最低条件
目的は、SQL記述から冗長な部分を省いて永続化処理の生産性を上げること
0169デフォルトの名無しさん
2006/08/07(月) 00:28:57・エンティティとデータの関係を言語ソースの外に出せること(>164)
・SQLとオブジェクトのマッピング作業をフレームワークがやってくれる(>167)
・SQL記述から冗長な部分を省いて永続化処理の生産性を上げる(>168)
色んな表現があるが、同じことを意味している？
0170デフォルトの名無しさん
2006/08/07(月) 00:55:58ソースで示してくれんかの？
0171デフォルトの名無しさん
2006/08/07(月) 01:14:48ResultSet rs;
・・・
Bean bean = new Bean();
bean.setProperty01(rs.getString("column01"));
bean.setProperty02(rs.getString("column02"));
bean.setProperty03(rs.getString("column03"));
bean.setProperty04(rs.getString("column04"));
bean.setProperty05(rs.getString("column05"));
bean.setProperty06(rs.getString("column06"));
bean.setProperty07(rs.getString("column07"));
bean.setProperty08(rs.getString("column08"));
bean.setProperty09(rs.getString("column09"));
bean.setProperty10(rs.getString("column10"));
・・・
上記のような単純で退屈でコピペミスしやすく、
しかし大量に書かなければ行けないような処理を、
テーブル毎・検索処理毎に書かなくて良い。
上記のコードを手書きするとカラム名やカラムの型を間違える可能性もあるが
マッピング定義ファイルを自動生成すればカラム名やカラムの型を間違えることもない。
カラムの追加変更があっても、このようなコードだと影響箇所を修正するのは骨が折れるが
マッピング定義ファイルを自動生成すればかなりの省力化が可能。
0172デフォルトの名無しさん
2006/08/07(月) 23:13:03オブジェクトをテーブル構造にマッピングするツール ○
RDBMSとオブジェクト指向言語との親和性を高めるツール ×
オブジェクトを永続化する先の入れ物としてRDBMSを使うためのツール ○
既存のテーブル構造にORMを適用する事も自動化ツールのサポートで容易 ×
ORMを使っていない環境で構築されたテーブル構造への適用は困難 ○
この辺りを理解してないORM信者も多すぎる。
所詮はラッピングツールであり、余程単純なシステムでもない限りSQL直書きは避けられない。
ここを勘違いすると、JAVAコードをすっきりさせるために一貫性の無いVIEWやストアドを大量に作成して
DBの中を阿鼻叫喚地獄絵図にしてしまうという本末転倒をやらかす。
0173デフォルトの名無しさん
2006/08/07(月) 23:18:47Java コードだけはすっきりしてるなんてありえないけどな。
0174デフォルトの名無しさん
2006/08/08(火) 01:04:35>ORMを使っていない環境で構築されたテーブル構造への適用は困難 ○
別に困難じゃなかったぞ
重要なのは適用検討しているテーブル構造の正規化の度合い
主キー無し、外部キー無し、結合条件がDBの制約では決まらないetcな構造だったら諦めるべきだが
普通に正規化されたテーブルなら適用は容易
ORMって結局DB側に寄ったツールであることを勘違いしてはいけない
SQL直書きサポート必須は同意。最近のツールはどれもサポートしてるけど
0175デフォルトの名無しさん
2006/08/08(火) 22:37:390176デフォルトの名無しさん
2006/08/09(水) 09:35:080177デフォルトの名無しさん
2006/08/09(水) 09:45:51なんでもかんでもSQLでやって、UIだけプログラムで作れば、
UI部分のプログラムにはカラム名を指定して値を一つ一つ取り出す記述や
入力値をSQLに埋め込む処理を大量に書くことになる・・・と。
0178デフォルトの名無しさん
2006/08/09(水) 13:38:460179デフォルトの名無しさん
2006/08/11(金) 21:52:500180デフォルトの名無しさん
2006/08/13(日) 14:35:290181デフォルトの名無しさん
2006/08/16(水) 18:20:020182デフォルトの名無しさん
2006/08/17(木) 06:07:000183デフォルトの名無しさん
2006/08/19(土) 23:01:51とりあえず本1冊読んでみたけど、組み込み向けじゃん。
0184デフォルトの名無しさん
2006/08/20(日) 00:12:50別に組み込み用では無いが。
0185デフォルトの名無しさん
2006/08/20(日) 16:12:060186デフォルトの名無しさん
2006/08/20(日) 23:25:440187デフォルトの名無しさん
2006/08/21(月) 21:09:59実際のところ、どうかは知らんが。
0188デフォルトの名無しさん
2006/10/07(土) 04:11:26いまどきJavaの世界にSQL持ち込んでる糞は氏んでよしと。
0189デフォルトの名無しさん
2006/10/07(土) 08:32:52思えんのだけど。
0190デフォルトの名無しさん
2006/10/07(土) 09:18:590191デフォルトの名無しさん
2006/10/07(土) 09:51:14(,,ﾟДﾟ) ﾖｲｼｮ....
/ つ～⌒ヽ
（ （';; _, ...,,）
∪,)....´;;;,,,..（ヽ
（::::::ノ⌒)_ヽ）
￣
∩⌒>⌒ヽ ｺﾞｿｺﾞｿ
/（';; _, ...,,）
（ ,)...´;;;,,,..（ヽ
U（::::::ノ⌒)_ヽ）
∧∧
/(*ﾟДﾟ) ｵﾌﾄﾝｻｲｺｰ♪
/ :::У~ヽ
(＿_ノ､＿_)
＿ ｶﾀｶﾀｶﾀ
.//|.| /'∧
| |..|.| (Дﾟ,ﾉ⌒ヽ ﾏｯﾋﾟﾝｸﾞｻｲｷｮｰ♪
￣ll ]-､と/~ ::ノ:::）
￣￣￣|(＿.( :: ,:_）
0192デフォルトの名無しさん
2006/10/07(土) 16:46:05今はtomcat + hibernate + postgres だけどそのうち時間があったらtomcat + db4oに変えてみる。
どれだけ生産性があがるかレポートしますね。
0193デフォルトの名無しさん
2006/10/07(土) 23:44:020194デフォルトの名無しさん
2006/10/08(日) 02:48:10Hibernate in Actionを一度読んでみるべき
「HibernateはSQLを熟知した開発者こそが使うべきツールである」
と開発者自身がはっきり宣言している
0195デフォルトの名無しさん
2006/10/08(日) 04:06:59知らないけど、既存データを捨てていいなら、自動じゃないの？
0196デフォルトの名無しさん
2006/10/08(日) 09:25:12１．SQLで以降処理を作る
２．変更後のDBは別のDBとして作り、マッピングベースで以降プログラムを作る
３．その他
どうするのがいちばんいいのか。
0197188
2006/10/08(日) 10:43:46はい、読んでます。
SQLの知識は必要ですよ。
それは否定してませんが。
ただ、
ソース上にSQLを直書して、
StringBuffer#appned
なんて、まじありえない。氏んでよし。
0198デフォルトの名無しさん
2006/10/08(日) 10:51:38お前が氏ねよ。って思います。
0199デフォルトの名無しさん
2006/10/08(日) 10:58:39こんな感じ？(jdbc 直というのはあんまりやったことがないので心許ないが・・・)
それほどダメとも思えないが・・・。
public class HogeHogeDAOImplJDBC implement HogeHogeDAO {
public void appendHogeHoge( HogeHoge hoge ) {
・・・
Statement sql;
・・・
sb.append( "INSERT INTO HOGEHOGE VALUES(" );
ab.append( hoge.getValue1().toString() );
sb.append( "," );
ab.append( hoge.getValue2().toString() );
sb.append( ")" );
・・・
sql.addBatch( sb.toString() );
sql.executeBatch();
}
}
0200デフォルトの名無しさん
2006/10/08(日) 11:12:08普通はResourceBundleやPreparedStatementを組み合わせるからな。
「SQLを使う」イコール「直書&StringBuffer」なんて発想の奴はHQLも直書するんだろうねｗ
>>199 それはいくらなんでもダメだよ。
0201188
2006/10/08(日) 11:29:54あなたの言うことは正しい。
SQLを外だしにして、管理しているならまだましだ。
だが、現実はコンサルと称して、そんなことすら
できない無能な奴がいる。
理由は
「複雑なＳＱＬが多いので、ハードコーディングじゃないと
やりにくい」
などと言っていたよ。
そういうやつらはまじ氏んでいいよ。
ただ、ResoureBundleを組み合わせるといっているが、
ようするにそういう場合、ある種のフレームワークを
作っているんだと思うが、そういうフレームワークでは
Hibernateが最強なんだよ。
かけられている工数、開発者のレベルが世界トップクラスだし。
0202デフォルトの名無しさん
2006/10/08(日) 11:35:50>>>199 それはいくらなんでもダメだよ。
なんで？
0203デフォルトの名無しさん
2006/10/08(日) 12:09:51とりあえず、単発のSQLなら判らないことは無いがPreparedStatementを使うほうがベターかな？
あと、サニタライズやなんかをどうするって話も出てくる
SQLインジェクションって言われる脆弱性のほとんどは>>197みたいなソースを使ってることが原因
0204デフォルトの名無しさん
2006/10/08(日) 12:51:14「いまどきJavaの世界にSQL持ち込んでる糞は氏んでよし」って言ってるじゃん
HQLだってSQLのテーブル定義をクラスに置き換えて、結合条件を省略したり継承戦略追加してるだけだし
ソース上に書くかNamedQueryで外出しするかはHibernate使っても選択肢の一つでしかない
>>199のような書き方は、JDBC使ってても普通やらないしｗ
0205デフォルトの名無しさん
2006/10/08(日) 13:17:29JPAでいいだろ。
コンテナにJBossやjboss-EJB-3.0_Embeddableを使った場合に
JPA実装としてHibernateを内部的に使うことはあるかもしれないが。
0206デフォルトの名無しさん
2006/10/08(日) 13:33:03それは、jdbc を使う（と決めた）場合の技法の問題であって、
後からいくらでも（DAO内部の問題として他に影響を与えずに）
修正の利く問題じゃないの。
0207デフォルトの名無しさん
2006/10/08(日) 13:42:20話がずれてないか？
0208デフォルトの名無しさん
2006/10/08(日) 14:07:05だからさ、SQL直に書かずに済むなら、
そのほうがいい、ってことは誰も否定してないだろう。
自分が言っているのは、じゃあ、SQL直書きが、
「それほど（SQLのコードがわずかでも存在したら、そのシステムが全否定されるほど）深刻な問題なのか？」ということ。
0209デフォルトの名無しさん
2006/10/08(日) 17:29:54パラメータをPreparedStatementで代入することと、SQL直書きが混同されて話されてるからな
前者はJDBCでやるときも同じだから、別にHibernateを選ぶ理由にはならない
後者は別に目くじら立てて否定するようなことでもない。
動的にクエリを組み立てるときはソースに書いたりすることもある。
Criteria使うこともあるだろうけど、JPAでサポートされてないからな
0210デフォルトの名無しさん
2006/10/08(日) 19:25:28joinしまくったSQLの生成とかできるの？
これができるのなら導入もありなんだが
0211デフォルトの名無しさん
2006/10/08(日) 19:30:110212デフォルトの名無しさん
2006/10/08(日) 23:59:48JOIN程度ならHibernate使ったほうが楽
SELECT句やWHERE句ならサブクエリも書ける
0213デフォルトの名無しさん
2006/10/09(月) 10:17:13JPAの実装ってどこにあるの？
0214デフォルトの名無しさん
2006/10/09(月) 10:55:28Hibernate EntityManager
0215デフォルトの名無しさん
2006/10/09(月) 12:07:17つ JBoss EJB3（JPA部分の実装はHibernate）
つ Glassfish/JavaEE SDK（JPA部分の実装はToplink）
0216デフォルトの名無しさん
2006/10/09(月) 13:12:13ん？db4oの話だよね？
リファクターは既存のクラスをさわらないで、新しいクラスを作りそこで行う
既存のクラス＞新しいクラスへの変換methodを適当につくる。
既存のクラスを全部ロード>新しいクラスに変換、全部保存
これで既存データもリファクター完了。
既存sqlからのデータ抽出はhibernate使ってれば上記プロセスでOK
jdbcだったら ちょっとつらいかな。
0217デフォルトの名無しさん
2006/10/09(月) 14:19:15っていうかSQL直書きに拘るならよさげなんですが。
0218デフォルトの名無しさん
2006/10/25(水) 18:27:25,r::::l3ﾞ::::::::/ﾊヽ:ヽ::::､:ヽ
{::://:::::::// ヽ＼ﾄ､:::::::!
ヾ l:::::::/ 丶 ｀ヾ ｨ､:::|
|;:r::| Ｏ` 'Ｏ ﾞﾊ| ORマッピング！？
ヽﾊ :.:. :.: ﾚ
´＼ r‐--‐､,ノ いらんいらん
r､ r､／ヾ￣下ヘ
ヽヾ 三 |:l1､＿ヽ/__ .ィヽ
＼>ヽ/ |｀ ｝ n_n| |
ﾍ lノ `'ｿ lﾟωﾟ| |
/´ / ￣|. |
＼. ｨ ＿＿＿ | |
| ﾉ l | |
0219ななすぃ
2006/11/07(火) 22:37:39るためのインフラなんだよ。SQLで書けないシステムなんかつぶし効かんからあと
あと苦労するよ。わかってないやつが集計処理をループで書いたりすんだよな。
0220デフォルトの名無しさん
2006/11/07(火) 23:21:34RDBMSって長期保存のデータストレージとしては最低最悪の場所だから。
0221デフォルトの名無しさん
2006/11/08(水) 13:25:260222デフォルトの名無しさん
2006/11/08(水) 15:59:08CPUの負荷が爆発的に上がってシステムダウンしたりするの。
ある程度、容量に限度があるってことと、
OSの更新の時のデータの移行とかの問題もある。
だから、分離だけが目的ならDBを使うべきじゃない。
0223デフォルトの名無しさん
2006/11/08(水) 22:16:370224デフォルトの名無しさん
2006/11/08(水) 23:06:290225デフォルトの名無しさん
2006/11/08(水) 23:12:400226デフォルトの名無しさん
2006/11/08(水) 23:27:180227デフォルトの名無しさん
2006/11/09(木) 00:03:340228デフォルトの名無しさん
2006/11/09(木) 01:28:55インターフェースの統合とトランザクションの管理を解きつつ、
RDMSの導入しかないって決め付ける。
ロジックは正しいけど解答は一つではないんだよね。
0229デフォルトの名無しさん
2006/11/09(木) 09:59:54それだ
0230デフォルトの名無しさん
2006/11/09(木) 10:33:17見渡せる範囲ならスケーラビリティあるしでDBMS使って楽すりゃ良いだけじゃね
一線越えたときはうちの会社じゃおさらばした方が良いしな
0231デフォルトの名無しさん
2006/11/12(日) 11:13:29漏れAS/400(中身RS/6000の)を使っているけどDBの容量が増えたからって
CPUの不可が爆発的に上がるなんて事ないんだが･･･。
そりゃ、システム全体のDiskの容量が90%くらいになると
ちょっと遅くなったなぁ、とは感じるけど。
それってWindowsでAccessとかSQL Serverとかの話じゃねーの。
0232デフォルトの名無しさん
2006/11/12(日) 13:17:45ブロック分断されまくったまま放置してたとかそんなんでしょ。
0233デフォルトの名無しさん
2006/11/12(日) 13:36:27Disk I/OがボトルネックになってCPUのSYSが跳ね上がったことはあるよ。
当時DBのサイズは100GB弱程度でPostgreSQL8.1利用。
OracleならDiskの使い方がもっと上手いんだろうけど。
0234231
2006/11/12(日) 17:47:37それOracleとかPostgreがどーこーじゃなくて、最初のハードウェアと
OSの選定が間違っていたってオチかと。
AIXなりOS/400だと「ある一線」とかは体感しないんだが。
もしかしてWindowsとかLinux使っておいてトロくなるとか
言っているなら、それを基準に「RDBMSとは･･･」と語るのも
微妙なんだが。
0235デフォルトの名無しさん
2006/11/12(日) 20:01:22ハードウェアのリプレースの時、文字コードの問題もあるだろ。
営業のRDBMSマンセーは異常だと思う。
0236デフォルトの名無しさん
2006/11/12(日) 21:07:150237デフォルトの名無しさん
2006/11/12(日) 21:33:570238デフォルトの名無しさん
2006/12/21(木) 00:05:59他のもきっとおｋ
0239デフォルトの名無しさん
2006/12/23(土) 01:56:38オラクルなら同時更新も可能ですよ。
0240デフォルトの名無しさん
2006/12/23(土) 10:32:23スレ違いだと思うがAS/400は更新モードでロックしたら排他ロックするは当たり前だが。
Oracleは更新モードでロックして他人からも更新できたらそれこそ異常だと思うが。
ゴミアプリしか作れないロック恐怖症の初心者ゴミプログラマには
その方がいいかもしれんな。
0241デフォルトの名無しさん
2006/12/23(土) 10:34:500242デフォルトの名無しさん
2006/12/23(土) 11:52:240243デフォルトの名無しさん
2006/12/23(土) 15:48:52インデックスのないカラムに対して更新モードで全件検索する
SQL投げておいて「ファイルがロックする」とかヌカしていると思うんだが。
0244デフォルトの名無しさん
2006/12/25(月) 11:23:020245デフォルトの名無しさん
2006/12/25(月) 19:38:05ゴロゴロしてるからなぁ、アフォな設定のAS/400でもちょっとイジって
挫折したクチじゃね。
だからと言ってOracleﾏﾝｾｰもどーかと思うが。
0246デフォルトの名無しさん
2007/01/13(土) 14:03:29簡単に扱えるOracle最強ということで
0247デフォルトの名無しさん
2007/01/13(土) 17:43:43ただ初心者最強を言うならAccessとかODBCなEXCELじゃねーか？
0248デフォルトの名無しさん
2007/01/14(日) 12:08:09Accessでもある程度できるやつじゃないと
まともなものは作れない
0249デフォルトの名無しさん
2007/01/14(日) 14:51:240250デフォルトの名無しさん
2007/01/14(日) 19:37:14初心者(?)がADO.NETでアレコレするのと大差ない「まとも」なのが出来るだろ。
0251デフォルトの名無しさん
2007/01/28(日) 13:17:16継承関係にあるクラスをRDBテーブルへ定義する場合
どうするのが自然なのでしょうか？
一応型の識別子と派生クラスの属性もテーブルに定義しといて、基底クラスの
インスタンスの場合、無い属性はNullのまま保存する感じで考えています。
ただ、これだと派生クラスの場合は自然ではありますが、基底クラスにも派生の
情報を持つことになるので、どうなんだろう？と思ってしまいます。
0252デフォルトの名無しさん
2007/01/28(日) 13:29:38誰か参考までに何かないでしょうか？ソース貼付でお願いします。m(__)m
0253デフォルトの名無しさん
2007/01/28(日) 13:35:07http://www-06.ibm.com/jp/developerworks/java/050107/j_j-hibernate.html
0254デフォルトの名無しさん
2007/01/28(日) 14:11:54良い記事ですね。ありがとうございます。
この方法は実際の継承関係に当てはめたやり方ですね。やっぱりこっちがしぜんなのでしょうか。
たしかにこのやり方のほうが、設計的には良いと思いますし、スペース的にも
効率的ですね。ただ設計の良さを優先して、実装が複雑になっている感じもあります。検索速度的にも気になる。
まあORマッピングツールとか色々有るみたいなので、自動で
やってくれるから良い。といった感じなのでしょうか。
0255デフォルトの名無しさん
2007/01/28(日) 14:51:32その記事は２ページにわたってて、２ページ目にNULLをつかう>>251の方法もある。
ケースによって最適解がかわるので選択汁。
0256デフォルトの名無しさん
2007/01/28(日) 19:56:06次のページも有ったのですね。
とりあえず何か作って見ようと思い、参考図書を買いにいってました。
でRuby on Rails Up and Running(O'Reilly)を買ってきたのですが、ページ数の
割に内容があってなかなか良書です。
この本にちょうどテーブルの"ラッピング"(ORマッピングではない)についても
書かれていましたが、
Railsでは単一テーブル継承を使ってるようです。
0257デフォルトの名無しさん
2007/01/28(日) 23:55:36OODB使えってことだろ？
0258デフォルトの名無しさん
2007/01/28(日) 23:56:480259デフォルトの名無しさん
2007/01/28(日) 23:59:220260デフォルトの名無しさん
2007/01/29(月) 20:39:55ORマッピングはOODBが普及しないからあるんじゃないの？
0261デフォルトの名無しさん
2007/01/29(月) 21:32:150262デフォルトの名無しさん
2007/01/29(月) 21:35:30ちょっとくらい遅くても普及すると思う。
0263デフォルトの名無しさん
2007/01/29(月) 22:12:01せっかくあるんだからこれをオブジェクトの永続化先にしちまおうぜ？
ってのがORマッパだとおもわれ。
しかし、オブジェクトを永続化するって考え方はよくわかるんだが、よくある業務システムって結局帳票の電子化だろ。
抽出した情報のつまらんCRUDユースケースしかねーんだからドメインモデルなんていらなくね？
人がいます。属性は名前、空腹度、疲労度。操作には歩く、食べる、寝るがあります。寝ると疲労が回復します。そして人は永続化されます。
なんて実際の業務システムじゃやらねーよ。
そもそもオブジェクト名に「〇〇情報」って書いてある時点で、データとしかみてないしな。
0264デフォルトの名無しさん
2007/01/30(火) 00:43:59単なるExcelの延長線だよね、業務アプリのほとんどって。
二次元の表でほとんどのデータを表せて、
必要なナチュラルキーで結合してやればデータモデル完成。
後はそれのCRUDを用意してやればシステム完成ってことも多くない？
ORマッピングはそう言う典型的な業務システムを構築する際には
大変役に立つと思うんだけど。
ORっていうよりRelation->Objectの方向だね。
R/Oマッピングツールって呼んだ方が正確かも。
0265デフォルトの名無しさん
2007/01/30(火) 01:43:22よほど画期的なモンでもなければ・・・・
0266デフォルトの名無しさん
2007/01/30(火) 01:56:280267デフォルトの名無しさん
2007/01/30(火) 02:06:46ORACLEも出してるんだが・・・
0268デフォルトの名無しさん
2007/01/30(火) 02:11:120269デフォルトの名無しさん
2007/01/30(火) 02:55:05今月のDBMagazine見る限り一番良さそうだな
咽返るほどのORACLEの宣伝臭がしたけどｗ
0270デフォルトの名無しさん
2007/01/30(火) 17:45:20含むDAOクラスを自動生成してくれるものってないですか？
他の言語では、前に自分で作成したDBアクセスコード生成ツールを使って開発し
てますが、JAVAですでに同じようなものがあれば、自分で作らずに済みますので。
0271デフォルトの名無しさん
2007/01/30(火) 17:59:56君はどこに来てどのレベルで話をしているんだ？
0272デフォルトの名無しさん
2007/01/30(火) 19:04:23現在、Hibernateを使ったりもしてますが、DBの情報がマッピングされたBeanと
>>171のようなJDBC丸出しの基本的なDBアクセスコードを含むDAOクラスを
自動生成する、単なるコード生成ツールのようなものがあれば使いたいなと思
いまして。「ORマッピングはいらない」スレなんで、代わりになるようなもので、
Hibernateなどに比べてほとんど抽象化されていないものがあればなぁと思って
書いたのですが。なければ自分で作ります。
0273デフォルトの名無しさん
2007/01/31(水) 02:52:52新規のコネクションも作れなくなってしまった
なんでだろう？
0274デフォルトの名無しさん
2007/01/31(水) 02:55:570275デフォルトの名無しさん
2007/01/31(水) 23:28:47なんかＥｃｌｉｐｓｅというかＢＥＡ Workshop for JSPがおかしい
0276デフォルトの名無しさん
2007/02/06(火) 21:22:40俺的にはこれで十分。
ボタンをクリックするだけで、DBのスキーマからJavaBeanとDAOクラスのコード
を自動生成するという簡単なものだけど。
DAOは、挿入・更新・削除・検索などの基本コードに加えて、自分が比較的よく
使うメソッドが、JDBC丸出しのコードで作られる。
まあ、かなり原始的だけど、フィールド数が仮に何百あろうとボタンをクリックする
だけで必要なフィールド数や型に合わせてコードが一通り自動生成されるから、
1から作るよりはかなり時間の節約になるよ。
細かいことは自動生成されたコードをカスタマイズして作らないといけないけどね。
0277デフォルトの名無しさん
2007/02/06(火) 21:43:530278デフォルトの名無しさん
2007/02/06(火) 22:18:18車輪にすらならんだろ・・・生ゴミ生成機だろ
0279デフォルトの名無しさん
2007/02/06(火) 22:55:59完全な自己満の世界
0280デフォルトの名無しさん
2007/02/07(水) 23:58:29とかでは、コード自動生成スクリプトとか良く作ったりするよ。
javaだってそういうケースはあるんじゃない？
それに1つのプロジェクトで複数言語使うこと多いし、無駄じゃないだろ。
0281デフォルトの名無しさん
2007/02/08(木) 00:02:260282デフォルトの名無しさん
2007/02/09(金) 01:43:28>>270の公開ｵﾅﾆｰを観賞するスレ
0283デフォルトの名無しさん
2007/02/09(金) 03:48:33シリアライズして外部プロセスと通信するならRDBとやってることが変わらないわけで。
0284デフォルトの名無しさん
2007/02/14(水) 00:13:47っていうかそれっぽいAPI用意してくれれば良いきがするけどな。
近いうちに、今のようなDBじゃなくてネットワークにつながるもの全てが
OODBというかオブジェクトで、接続先のクライアントも、クエリーで指定して
つながるような分散型のが出てくるんじゃない？
現実的にはCAみたいな物が居て、IP電話なんかと同じだろうけど。
簡単なAPIというかIFがあれば電話やIMなんかはかなり楽に作れるようになる。
まあ標準化がうまくいけばだけど。
0285デフォルトの名無しさん
2007/02/14(水) 11:38:36一緒にしたログを出すことはできないでしょうか？
select ? from XXX
BBB
↓↓↓↓↓↓↓↓↓↓↓↓
select BBB from XXX
0286デフォルトの名無しさん
2007/02/14(水) 16:28:38SQL文をハードコーディングするやつはとっとと氏ね＠マ板
http://pc10.2ch.net/test/read.cgi/prog/1170779576/
0287デフォルトの名無しさん
2007/02/14(水) 16:59:410288デフォルトの名無しさん
2007/02/14(水) 17:29:00ないよ・・・
0289デフォルトの名無しさん
2007/02/14(水) 21:13:53だから逆にiBATIS使ったら病み付きになると思う。
0290デフォルトの名無しさん
2007/02/14(水) 22:22:00数個のテーブルと簡単な仕様を提示して、各々がアプリを作ってみると
O/Rマッパー使う派/使わない派のコードとかいろいろ見えてきておもしろいと思うんだけど
どうだろうか。
0291デフォルトの名無しさん
2007/02/14(水) 22:58:06何度も言わすな。
0292デフォルトの名無しさん
2007/02/14(水) 23:11:020293デフォルトの名無しさん
2007/02/15(木) 11:57:280294デフォルトの名無しさん
2007/02/15(木) 21:51:52おまいらがORMに無きゃいけないと思ってるプロパティというのはなんだ。
0296デフォルトの名無しさん
2007/02/17(土) 14:35:18>>291って何かおかしいの？
0297デフォルトの名無しさん
2007/02/17(土) 14:36:520298デフォルトの名無しさん
2007/02/17(土) 14:41:43先にテーブル渡されて、ORM使う派と使わない派がコードを提示しあったら
ORM使う派のほうがあきらかに不利だとおもうんだけど。。
0299デフォルトの名無しさん
2007/02/17(土) 14:43:220300デフォルトの名無しさん
2007/02/17(土) 14:50:16俺はそのやり方にちょっと懐疑的なんだけど。
ドメインモデルがトランザクションスクリプト・テーブルモジュールと比べて
有利な点ってモデル設計の自由度由来で
オブジェクト指向の恩恵を引き出しやすいことだけでしょ。
なのにテーブル構造に引きずられてモデル構造が決定されてしまったら
複雑さっていうデメリットだけが残るんじゃね？
0301デフォルトの名無しさん
2007/02/17(土) 15:02:530302デフォルトの名無しさん
2007/02/17(土) 15:04:450303デフォルトの名無しさん
2007/02/17(土) 18:48:520304デフォルトの名無しさん
2007/02/17(土) 19:51:49インピーダンスミスマッチってやつを解消することそのものがORMであって、
自動化とかそういうのはオマケだろ。
0305デフォルトの名無しさん
2007/02/17(土) 20:40:12そもそもORM用に適したテーブル設計しなきゃいかん時点でORM使えねってことでしょ
0306290
2007/02/17(土) 21:48:31スレ読んでても実装の話が出てこないのでイメージが掴めなかったんだよ。
だから実際にコードにしたらよく分かるんじゃないかと思って話を振ってみた。
個人的にはどうやってオブジェクトを切り出すとか、途中でどうやって改良するとかを知りたい。
テーブルありきだろうがそうじゃなかろうが、その辺はあまり重要視してなくて
束縛が仕様だけだと自由度高すぎるかなとおもって制約付けただけ。
ちなみに俺はORMに対しては>304の認識と一緒。
0307デフォルトの名無しさん
2007/02/17(土) 21:54:090308デフォルトの名無しさん
2007/02/17(土) 21:58:29ここでコードを提示したとしても良さも悪さも伝わらんと思うけどなあ。
0309デフォルトの名無しさん
2007/02/17(土) 22:19:02>そもそもORM用に適したテーブル設計しなきゃいかん時点でORM使えねってことでしょ
どういう理屈だよ。
0310デフォルトの名無しさん
2007/02/17(土) 22:25:040311デフォルトの名無しさん
2007/02/17(土) 22:44:55全部ORMでやろうとしたり、全部SQL直打ちでやろうと考えるからおかしくなる。
0312デフォルトの名無しさん
2007/02/17(土) 22:48:48実際そういった設計少ないけどな・・・
もう疲れたよﾏﾏﾝ・・・
0313デフォルトの名無しさん
2007/02/17(土) 22:56:33っていうか、ここでぎろんされているORMの定義がわからん
たとえばHibernateのような実装の事をいっているんか、理論の事をいってるのか
わしは理論はいらん
実装は、バインディングツールとして使える
0314デフォルトの名無しさん
2007/02/17(土) 23:07:53ん？OOPのメリットがわかれば自明だろ。
それとも、永続データついてはOOPは諦めればいいの？
0315デフォルトの名無しさん
2007/02/17(土) 23:12:29理論って言うほど大層なものは無いと思うぞ。
つか、オブジェクト指向ｲﾗﾈなら無条件でORMｲﾗﾈで正しい。
0316デフォルトの名無しさん
2007/02/17(土) 23:15:32どの道現状では、永続化データのOO化は、メリットより
デメリットの方が勝ってしまっているからねぇ
0317デフォルトの名無しさん
2007/02/17(土) 23:21:28現状っていつの現状だよ。
5年前だったらあんたの言ってたことで正しかったよ。
0318デフォルトの名無しさん
2007/02/17(土) 23:24:140319デフォルトの名無しさん
2007/02/18(日) 00:06:32そしたら、RDBのような可汎用が保てないからダメよな。
0320デフォルトの名無しさん
2007/02/18(日) 00:18:57それだけなら言語依存しないようにできるように思うけど
言語用のドライバとかで読み込めばインじゃね？
0321デフォルトの名無しさん
2007/02/18(日) 05:59:590322デフォルトの名無しさん
2007/02/18(日) 12:39:30>>311の言ってることが核心を突いてると思うのだが。
結局、RDBとオブジェクト指向言語の間に
完全なインピーダンスミスマッチの解消を求めること自体が間違っている。
>>つか、オブジェクト指向ｲﾗﾈなら無条件でORMｲﾗﾈで正しい。
"オブジェクト指向ｲﾗﾈ" な部分をPG内に意図的に設けるのが、結局◎だと思う。
そもそもその部分を隠蔽化する役割もORMapperにはあるんだろうけど、抽象化の漏れがありすぎる。
>>313の言うようなバインディングツールとしての使い方に押さえるぐらいが、
最終的に一番幸せになれるんじゃないかね。
0323デフォルトの名無しさん
2007/02/18(日) 16:46:50JDBCっぽいつかい方も出来るし、その上問い合わせ結果とのマッピングも
やってくれるのはお得だ。
0324デフォルトの名無しさん
2007/02/18(日) 21:45:56もちろんあってもかまわないが、他の選択肢もあるように思う。
たとえばADO.NETは厳密な意味でのORMじゃないんだよね。
あれはR-OマッピングというかXMLスキーマ中立型マッピングというか割と独特な構造をしている。
とにかく何を指して、いるいらないを議論しないと始まらない。
0325デフォルトの名無しさん
2007/02/20(火) 20:37:04といってみる
0326デフォルトの名無しさん
2007/02/20(火) 23:44:43SQLチューニングできない。SQLの便利な関数が使えない。
0327デフォルトの名無しさん
2007/02/20(火) 23:55:200328デフォルトの名無しさん
2007/02/20(火) 23:57:300329デフォルトの名無しさん
2007/02/21(水) 07:08:36>SQLチューニングできない。
Session#createSQLQuery
>SQLの便利な関数が使えない。
org.hibernate.dialectにDB毎の関数を登録しているDialectがあるのでHQLでも使える
0330デフォルトの名無しさん
2007/02/21(水) 16:26:23そんなだからゲッティになるんだよ。
0331デフォルトの名無しさん
2007/02/21(水) 19:30:050332デフォルトの名無しさん
2007/02/21(水) 21:14:47同意。ORMみたいな隠蔽の恩恵はOOLだけが受けるものじゃないと思う。
>>331
だいたいjavaなんてcobol2.0だろ。
コボラとも仲良くやれば良いんじゃね。
0333デフォルトの名無しさん
2007/02/21(水) 22:16:41> cobol2.0
ｴｴｰ
本当にそうならよかったと思うことあるけどさ
0334デフォルトの名無しさん
2007/02/22(木) 01:00:46>だいたいjavaなんてcobol2.0だろ。
こんなこという奴にOOわかんのか？
0335デフォルトの名無しさん
2007/02/22(木) 01:10:50OOだの技術面でしか考えられないような
人が使ってるようではやっぱりjavaはcobol2.0。
まあ長い事だらだら食えそうという事でもあるな。
0336デフォルトの名無しさん
2007/02/22(木) 01:16:04そういうことじゃないだろ。
視野狭すぎ。
0337デフォルトの名無しさん
2007/02/22(木) 08:31:03COBOLを名乗るならもっと帳票作りやすくしてくれ。
0338デフォルトの名無しさん
2007/02/22(木) 10:04:33レポーティングツールとしての機能は
SQLに吸収されたと考えてはどうでしょか。
データの整形だけの話だけど。
0339デフォルトの名無しさん
2007/02/22(木) 11:51:27あほですか？
0340デフォルトの名無しさん
2007/02/22(木) 12:26:03あんなキモイもの誰も使わないだろ。
0341デフォルトの名無しさん
2007/02/22(木) 22:53:58違いますよ、クロス集計だなんだの話。
みんなSQLでやらないの？
0342デフォルトの名無しさん
2007/02/22(木) 23:11:400343デフォルトの名無しさん
2007/02/22(木) 23:14:350344デフォルトの名無しさん
2007/02/22(木) 23:25:57「俺は最高級の炊飯ジャーを使ってるよ」
「なんで焼肉の話してるのに炊飯ジャーの話が出てくるわけ？」
「焼肉に白いご飯はつき物だからだろ？」
0345デフォルトの名無しさん
2007/02/22(木) 23:47:43帳票しかやった事ない人にはわからん話だよなあ。
俺はCOBOLの事は知らないけど
業務に使う様々な帳票に出力するデータを
作るのに向いてたって読んだ事がある。
WEB+DBプレスかな。その記事はSQLだか
RDB絡みの話だったな。>338と主旨は一緒。
その記事読んだんじゃないのかな。
0346デフォルトの名無しさん
2007/02/22(木) 23:50:28帳票レイアウトを簡単に作れる
Accessみたいな環境作れ、てな
意味だったら話がすれちがっちゃってますな。
0347デフォルトの名無しさん
2007/02/23(金) 00:02:01Hibernateには一応、独自のSQL構文をサポートしているが
0348デフォルトの名無しさん
2007/02/23(金) 00:08:40今なら、EclipseのBIRT
帳票作成はＢＩＲＴで決まり！
0349デフォルトの名無しさん
2007/02/23(金) 00:50:07つーかSQL書くの面倒だから１行丸ごとloadする問い合わせばっかりしちゃうｗ
0350デフォルトの名無しさん
2007/03/20(火) 01:17:420351デフォルトの名無しさん
2007/03/20(火) 01:33:150352デフォルトの名無しさん
2007/03/20(火) 03:01:42漏れが最初に使ったつもり。
0353デフォルトの名無しさん
2007/03/20(火) 06:50:13なんというジジイｗ
0354デフォルトの名無しさん
2007/03/31(土) 12:22:52JDBCかつ全てPreparedStatementってのが最強かなと思ってるんだけど、
上のような簡易なライブラリってないのかな。Dbutilsみたいな感じで。
PreparedStatementは早いし、SQLインジェクション対策してくれるからいい。
0355デフォルトの名無しさん
2007/03/31(土) 12:39:08ただ、バインダー目的で使うとJDBCのようには逝かない場合があるからなー
0356デフォルトの名無しさん
2007/03/31(土) 18:21:33iBATISはどうなん？
S2Daoも結局は結局はPreparedStatementつくるO/Rﾏｯﾊﾟｰだし。
しかし、当たり前だがJDBCよりもちょろっと遅いんだよな。
この辺りは楽してる反動なので仕方ないと思うが。
0357デフォルトの名無しさん
2007/03/31(土) 20:50:530358デフォルトの名無しさん
2007/03/31(土) 20:57:07「O/Rマッパー使ったらJDBCより早くなりました」とか言われたら
それこそクソコーダー認定だと思うが。
0359デフォルトの名無しさん
2007/04/01(日) 02:02:00それでも十分にメリットがある速さなのかどかって言うのが問題でして・・・
0360デフォルトの名無しさん
2007/04/01(日) 02:47:57それすら判らないんだから放っておけばいいんだよ
0361デフォルトの名無しさん
2007/04/01(日) 03:53:260362デフォルトの名無しさん
2007/04/01(日) 09:50:22生産効率悪けりゃ要件の実現性が低くなるし
製品の安定性だって悪くなるし
保守効率悪けりゃメンテコストかかるし、新機能追加の実現性も低くなる
もっともそれを無理やり開発サイドが受け入れてデスマってパターン
なのかも知れないけどｗ
0363デフォルトの名無しさん
2007/04/01(日) 13:35:300364デフォルトの名無しさん
2007/04/02(月) 22:35:51いまいちORに手を出せないってのが俺の困ったところ
0365デフォルトの名無しさん
2007/04/03(火) 00:08:22困ったところはそこじゃないだろ？
0366デフォルトの名無しさん
2007/04/03(火) 08:37:08いい事あるさ
0367デフォルトの名無しさん
2007/04/06(金) 00:54:19SQLの書き方一つで速度が激変することは良くある。
それ考えると、動的生成に頼るのはちょっと不安があるな。
0368デフォルトの名無しさん
2007/04/07(土) 01:48:15どの道複雑なSQLは自分で書くしかなかとね
0369デフォルトの名無しさん
2007/04/07(土) 11:31:15昔あったTorqueはなくなったのかな。ちょっと現場離れると機能レベルの変更についてけないや。
ORだのDIだの、学習コストかかるし、
どういうメリットがあるのかかわからん。
再利用性云々とか、疎結合だの、N階層だの…ほんとに再利用してる？
ほんとにメンテナンスコスト上がってる？
生産性あがってる？
プロジェクト運営とか、もっと根本的な所を改善しないとこういうのは解決しないのでは。
結局のところ、みんなが知ってるJDBCで十分というのが俺の結論。
Struts1.2とJDBCとTomcat5をみんなが覚えれば、WEB系の奴は幸せになれるんじゃないの。
これ以上はよっぽど革新的な技術が出ない限り、手をつける必要がないのではと。
以上グチでした…
0370デフォルトの名無しさん
2007/04/07(土) 12:11:44メンドクサイ・わからない・覚えられないってだけだろ？
君の能力が足りてないだけ
0371デフォルトの名無しさん
2007/04/07(土) 12:21:15俺もそう思う。
ついて行けてないだけじゃないか。
生産性・メンテナンス性は格段に上がってるよ。
学習コストとパフォーマンスがトレードオフになるけどな。
0372デフォルトの名無しさん
2007/04/07(土) 13:09:01IBM JSF+SDOくらいだとポトペタ(というのか？)でWebアプリが作れる。
単純なのならほとんどコードを書かずに作れる。
おそらくはひとつの理想系だと思う。
かなり革新的だと思うが、誰も話題にしない。ｗ
0373デフォルトの名無しさん
2007/04/07(土) 16:05:020374デフォルトの名無しさん
2007/04/07(土) 19:50:15所謂、定型的な力技作業が省力できるだけであって、
決して大幅なコスト減ってわけではなさそうな気がするけど。
それより、導入することによる学習コストや引継ぎのメンテナンスコストはかかるような
気がする。初期は解決できないエラーとかに悩まされるし。
372が言ってるのは、コードレスのGUIツール？だよね。genexusとか…
開発工程では、それくらい抜本的なものじゃないとコスト減らせないな。
あと、オフショアくらいか。
なんか話が脱線してるな… これにて失礼。
0375デフォルトの名無しさん
2007/04/07(土) 19:53:33大規模開発だと分業や保守のために面倒なルールや手順を踏んだほうが全体的な開発効率が上がってる。
この辺がJSFが流行らない理由のように思える。
0376デフォルトの名無しさん
2007/04/07(土) 23:24:29これって、その開発の時だけ効率が上がったような錯覚を受けるんだけどさ、
実際、ポトペタの人海戦術(?)の方が生産性高いんじゃないか？って常々思うんだが。
あとで、そのシステムの拡張や保守・リプレースとかやりだすと、
後任者って大抵元チームよりスキルが下もしくは少人数だったりするんだが、
その面倒ルール＆手順を再学習ってコストがバカにならんし。
でJSFのEase-of-Use, Standardization, Device Independenceのアプローチは
正しいと思う。
JSFで簡単に成果物が出来るのは素直にありがたい。
とか言う漏れはJSF+SDO+SpringFramework+iBATISが一番理想だと思っているが。
0377デフォルトの名無しさん
2007/04/07(土) 23:38:14(velocity+自作マクロライブラリ)+改造struts+spring+自作DAO
0378デフォルトの名無しさん
2007/04/07(土) 23:51:10俺専用ザクって感じだな
0379デフォルトの名無しさん
2007/04/07(土) 23:56:13ポトペタ部分が無いんだよなー
Javaで作ると動き悪いからなー
0380デフォルトの名無しさん
2007/04/07(土) 23:57:18ポトペタUIの部分の事
0381デフォルトの名無しさん
2007/04/08(日) 03:02:23簡単なCRUD処理ならウィザードですぐ作れるし
0382デフォルトの名無しさん
2007/04/08(日) 11:09:46簡単にウィザードで作れるって言うのは、簡単に作れるものしか
簡単には出来ないんだよねー
ソコから一歩飛び出ると結局同じ的な・・・・
0383デフォルトの名無しさん
2007/04/08(日) 16:01:49ウィザードってそういうもんだと思うよ
0384デフォルトの名無しさん
2007/04/08(日) 17:10:050385デフォルトの名無しさん
2007/04/08(日) 17:47:11使ったことないだろうから、そういう印象があるのだろうけど、
たとえばJSFだとJSF以上の事は出来ない。
それを指して簡単なのしか出来ないというのなら解らなくも無いが、
「servlet+JSPならこんな事も出来るぜ！」と言う話なら、
フレームワークなんか使うなよ、って話になるから勘弁な。
しかし、平均的(?)なプログラマの技量だとJSFでウィザートつかった方が
servlet+JSPよりも遥かに凝った事が出来ると思うが。
0386デフォルトの名無しさん
2007/04/08(日) 19:50:57そうだなぁ。
けど一番恐ろしいのはJSFへの習熟度が低いが為に、
JSFの機能で提供されているものを力技実装をされた
カオスなシステムが出来上がる事だと思うんだ。
うちでも出て間もないフレームワークを採用したプロジェクトは酷いもんだ。
ベストプラクティスを知らないが為に酷い実装になってしまったプロジェクトの多いこと。
0387デフォルトの名無しさん
2007/04/08(日) 20:52:12SUNのJSF RIで「JSFはあれくらいしかできん」と誤解されているのかもしれんな。
漏れはIBM JSFの人だけど、カレンダーとかの部品もあるし、
RDBへのアップロードやダウンロードなんかもムチャ簡単に実装できる
拡張コンポーネントとかあったりするので、フレームワークの選択は慎重に、
ってのはあるな。
どのフレームワークでもあることなんだが、フレームワークにない機能を
実装しようと思うと、とたんに面倒＆泥臭いコーティングが始まるので、
そういうのが嫌でフレームワークを嫌うヤツはいるかもな。
JDBCでいいじゃん、と言うのもそういうある境界を越えたときの泥臭さが嫌で主張しているんだろうし。
0388デフォルトの名無しさん
2007/04/09(月) 17:07:53Strutsは2.0系のほうが学習コストもメンテコストも大幅に下がると思うぜ
別物になってるけど
今はHibernate専用よりJPA汎用で実装をきりかえれるようにしておくのが都合がいい
>>387
JavaEE5だろ？というつっこみはおいといてNetBeansのJSFコンポーネント、
つまりRaveのものだけど、他社と同じくカスタムしまくりで素のコンポーネントは誰も使わんよ
今までだってSwing等GUIコンポーネント使ったアプリも配置だけですらIDE間で互換性はないし
JBuilderは知らないうちに組み込まれるようになってるから、誰でも気がついてると思いたい
0389デフォルトの名無しさん
2007/04/09(月) 21:00:260390デフォルトの名無しさん
2007/04/09(月) 21:28:47ツールのサポートもあるしな
0391デフォルトの名無しさん
2007/04/09(月) 21:53:34切り替えは現実的にない希ガス。
まあ、今後の新規アプリは、ってならJPAで無難だとは思うけど。
0392デフォルトの名無しさん
2007/04/09(月) 22:00:39十分非現実的な希ガスｗ
0393デフォルトの名無しさん
2007/04/11(水) 01:09:13@NamedNativeQuery(name="night&area", query="select night.id nid, night.night_duration, "
+ " night.night_date, area.id aid, night.area_id, area.name "
+ "from Night night, Area area where night.area_id = area.id", resultSetMapping="joinMapping")
@SqlResultSetMapping(name="joinMapping", entities={
@EntityResult(entityClass=org.hibernate.test.annotations.query.Night.class, fields = {
@FieldResult(name="id", column="nid"),
@FieldResult(name="duration", column="night_duration"),
@FieldResult(name="date", column="night_date"),
@FieldResult(name="area", column="area_id"),
discriminatorColumn="disc"
}),
@EntityResult(entityClass=org.hibernate.test.annotations.query.Area.class, fields = {
@FieldResult(name="id", column="aid"),
@FieldResult(name="name", column="name")
})
}
)
0394デフォルトの名無しさん
2007/04/11(水) 01:37:32なにこれ？最近のアノテーションベースのフレームワークってこんなの書かせてるの？
こんなの書くぐらいならまだメソッド内に実装した方がまだ見やすいわｗｗｗ
0395デフォルトの名無しさん
2007/04/11(水) 01:44:000396デフォルトの名無しさん
2007/04/12(木) 18:58:37正直DAOパターンに特化して、洗練させる方向で開発して欲しい気分。
うちはExcelとかCSVとかもよく使ってのと、
JDBCのが汎用性高いってのがその理由。
0397デフォルトの名無しさん
2007/04/12(木) 19:53:200398デフォルトの名無しさん
2007/04/12(木) 22:00:460399デフォルトの名無しさん
2007/04/14(土) 00:16:31自分でDAO書いてJDBCごりって終わり。
そら永続化ツールの洗練されたキャッシュ機構に比べたら遅くなるが
それがボトルネックになることはまずない。
JPAを否定する気は無いが、トラブルを抱え込みたくない。
0400デフォルトの名無しさん
2007/04/14(土) 00:36:560401デフォルトの名無しさん
2007/04/14(土) 00:49:290402デフォルトの名無しさん
2007/04/14(土) 00:50:24とりあえずDAOでファサードパターンになってるんだからどうにでもなるしな
0403デフォルトの名無しさん
2007/04/14(土) 07:47:14と言っても自前でORMやDIxAOP部分をコーティングしてるワケ？
たぶん、担当者が変わったら「あの自慰野郎」とか言われて恨まれるのがオチな希ガス
0404デフォルトの名無しさん
2007/04/14(土) 08:51:49情報照会系のアプリにはなんだが、マスター更新系ならｳﾏｰ
0405デフォルトの名無しさん
2007/04/14(土) 09:32:00SQLも発行できるORマッパーを利用して
情報照会はSQLで、編集・更新処理でEntity使いまくると
両者の長所が生かせてｳﾏｰだったよ
検索はSQLを駆使できて、更新系ではSQLを一切発行しなくていいからかなり楽
0406デフォルトの名無しさん
2007/04/14(土) 09:45:080407デフォルトの名無しさん
2007/04/14(土) 10:58:11xmlファイルに記述するスタイルのO/Rマッパー。
0408デフォルトの名無しさん
2007/04/14(土) 12:13:28ただ単に、WEBアプリケーションを作りたいだけでしょ？
それなら技術は限りなく絞って、もっと他の事にパワーを注いだ方がいい。
Servletだけで開発してた頃に比べて、顧客に提示する見積もり工数は減ったか？
主にI○Mを主体とした組織だけが、儲かってるだけじゃないのかな。
それに比べてVBはなんとすばらしいことか。クラサバだから目的は違うけどね。
Studioで用意されたものをさえ使えばいい。DB接続にしても、ADO使うのがスタンダードでしょ。
最終的には、Javaも周辺技術が統一されて、VBみたいなGUIライクな、
低レベルな開発に落ち着くような気がする。
Eclipseのような統合開発環境がアプリケーションフレームワークともっと密接に
パッケージングされた感じかな。
0409デフォルトの名無しさん
2007/04/14(土) 12:27:03フレームワークという名前にふりまわされてるやつ乙
自分が指揮できる立場ならちゃんとした環境用意できるだろ
Servletだけのときに比べて俺は大幅に工数は減ったよ
定型的な処理は任せてロジックだけに集中するのがフレームワークやライブラリというものだよ
VBサイコーでWEBアプリダメってのはまぁ言いたいことはわかるが
細かいことをやろうとするとVBにしろDelphiにしろ苦労してたなぁ
Swingは最初から低レベルライブラリなので同じ感覚で使うとはまる
まだバインディングAPIが標準化されてないからね
密接な連携ならEclipseはあきらめてNetBeansにするがよろし
0410デフォルトの名無しさん
2007/04/14(土) 12:56:46藻前は一度IBMのi5(AS/400)のJava+Web開発をやってみろ。
藻間の妄想程度のモノはすでにある。
#開発キットがやたら重いのが難点だが。
0411デフォルトの名無しさん
2007/04/14(土) 15:24:31Microsoft製品は一貫した開発環境、手法があるからJavaに比べると生産性が高い
そんな風に思っていた時期が、オレにもありました。
0412デフォルトの名無しさん
2007/04/14(土) 15:34:050413デフォルトの名無しさん
2007/04/14(土) 15:48:11VBはよーわからんけど、JUnitみたいなのってマイクロソフトが用意してくれるの？
ソースを変更せずにクラスのロギングとか、トランザクション制御とか出来るの？
>>412
ビジネスロジック部に関しては可能だな。ｗ
Javaから呼び出せるし。
0414デフォルトの名無しさん
2007/04/14(土) 15:54:08VBだろうが、何の言語だろうが顧客の望むシステムを高品質に作り上げたもん勝ち
流行ということで入力系をすべてWEBシステムに変えて大幅に生産性を下げた会社をいくつか知ってる
もちろん、コストや期間は大幅に増え、誰も得をしないという状態
WEBだと顧客は選択行が色が変わることとか、キーボードでの操作とか要望がどんどん膨らみやすいっぽい
用意されているコンポーネントを使える状況じゃないときの業務アプリでのJavaScript大量の直書きなんてまさに地獄
0415デフォルトの名無しさん
2007/04/14(土) 15:58:50漏れの周りでは普通に減っている点について
まあ、それまでのC/Sがヘボすぎたってだけだな。
つか>>414の周りはヘボエンジニア揃いって事か。
0416デフォルトの名無しさん
2007/04/14(土) 16:09:15＞顧客の望むシステムを高品質に作り上げたもん勝ち
だったらWebでも作れない事はないだろ。
鬼の様なパンチャーがいるデータエントリー系の処理だったら、そこだけ
>>412にRPGで入力画面作ってもらえ。VBなんか比にならんほど堅牢で生産性が高い。ｗ
厨房は適材適所で技術を使い分ける事を知らん上に知ったかをするからウザいな。
0417デフォルトの名無しさん
2007/04/14(土) 16:29:04WEBアプリになったあとリッチクライアント（いわゆる3層式C/S)に戻してるところは多いけどな
それも含めてのことだ
0418デフォルトの名無しさん
2007/04/14(土) 16:30:16適材適所が出来てないのは本当に困る
照会系はWEBでかまわんけど入力系では開発コストが上がることをちゃんと説明しない
マネージャーや営業は死ねよと
0419デフォルトの名無しさん
2007/04/14(土) 16:37:38つまり、藻前の周りの案件は最初デタラメなのをワザと納品しておいて
「やっぱアレはダメでしたね」と言い、さらに開発費をボる悪徳ベンダー、って事でFA
営業、開発とバカ揃いの組織でつな。
0420デフォルトの名無しさん
2007/04/14(土) 16:46:170421デフォルトの名無しさん
2007/04/14(土) 16:47:13っつうか営業とか案件の話はマ板でやれよ。
0422デフォルトの名無しさん
2007/04/14(土) 16:48:370423デフォルトの名無しさん
2007/04/14(土) 17:47:410424デフォルトの名無しさん
2007/04/14(土) 19:19:50Hibernateで使ってたHibernate固有のアノテーション使っていないクラスが
動かん・・・
0425デフォルトの名無しさん
2007/04/14(土) 19:58:430426デフォルトの名無しさん
2007/04/14(土) 20:30:42両方書かんと例外が出る。
0427デフォルトの名無しさん
2007/04/14(土) 20:38:490428デフォルトの名無しさん
2007/04/14(土) 21:39:23なにがわるいんかおせーてください・・・・
ttp://www.42ch.net/UploaderSmall/cgi-bin/../source/1176554246.zip
0429428
2007/04/14(土) 21:41:28Hogeクラスを実行してね
0430428
2007/04/14(土) 21:45:31DBはHSQLで、テーブルやデータはhsqldb\src\org\hsqldb\sampleにあるsampledata.sqlで作ってね
0431デフォルトの名無しさん
2007/04/14(土) 22:16:10DBつくるのめんどくさす
0432デフォルトの名無しさん
2007/04/14(土) 22:22:080433デフォルトの名無しさん
2007/04/14(土) 22:24:170434428
2007/04/14(土) 23:44:35解凍してhsql.batを実行すれば、java.exeへのパスが通っていれば動くはず
で、Hogeクラスを実行すると、↓の例外が出る。
Exception in thread "main" java.lang.IllegalArgumentException: Unknown entity bean class: class test.Customer, please verify that this class has been marked with the @Entity annotation.
at oracle.toplink.essentials.internal.ejb.cmp3.base.EntityManagerImpl.findInternal(EntityManagerImpl.java:291)
at oracle.toplink.essentials.internal.ejb.cmp3.EntityManagerImpl.find(EntityManagerImpl.java:133)
at test.Hoge.main(Hoge.java:17)
0435428
2007/04/14(土) 23:48:02～Hibernateのログは省略～
test.Invoice@15e3dc4
test.Customer@1aa5882
test.Invoice@2942da
test.Customer@1aa5882
test.Invoice@e3fd79
test.Customer@1aa5882
0436デフォルトの名無しさん
2007/04/15(日) 00:00:21persistence.xmlに<class>が無いから。
>>426の言うとおり。
0437428
2007/04/15(日) 00:15:36だよねー
ちなみに>>426はオレなんだけどねｗ
で、persistence.xmlのコメントをはずして<class>も<provider>も
ある状態にしても例外発生。
Customerに@OneToManyが付いてるのがイカンらしいがなんで？
Internal Exception: Exception [TOPLINK-7160] (Oracle TopLink Essentials - 2.0 (Build b41-beta2 (03/30/2007))):
oracle.toplink.essentials.exceptions.ValidationException
Exception Description:
@OneToMany for attribute name [invoice] in entity class [class test.Customer] should not have @JoinColumn(s) specified.
In the case where the @OneToMany is not mapped by another entity (that is, it is the owning side and is uni-directional),
it should specify (optional through defaulting) a @JoinTable.
at oracle.toplink.essentials.internal.ejb.cmp3.EntityManagerSetupImpl.predeploy(EntityManagerSetupImpl.java:615)
at oracle.toplink.essentials.internal.ejb.cmp3.JavaSECMPInitializer.callPredeploy(JavaSECMPInitializer.java:146)
at oracle.toplink.essentials.internal.ejb.cmp3.JavaSECMPInitializer.initPersistenceUnits(JavaSECMPInitializer.java:226)
at oracle.toplink.essentials.internal.ejb.cmp3.JavaSECMPInitializer.initialize(JavaSECMPInitializer.java:242)
at oracle.toplink.essentials.internal.ejb.cmp3.JavaSECMPInitializer.initializeFromMain(JavaSECMPInitializer.java:278)
at oracle.toplink.essentials.internal.ejb.cmp3.JavaSECMPInitializer.getJavaSECMPInitializer(JavaSECMPInitializer.java:81)
at oracle.toplink.essentials.ejb.cmp3.EntityManagerFactoryProvider.createEntityManagerFactory(EntityManagerFactoryProvider.java:119)
at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:83)
at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:60)
at test.Hoge.main(Hoge.java:15)
0438428
2007/04/15(日) 00:29:34お騒がせしました
@OneToMany(mappedBy="customer")
0439デフォルトの名無しさん
2007/04/15(日) 00:30:23自前で一から実装してミス犯すくらいならNetBeansですべて自動生成させたほうがよさそうだが
0440デフォルトの名無しさん
2007/04/15(日) 05:15:07Hibernateでいーや
0441デフォルトの名無しさん
2007/04/15(日) 07:46:11好きな形に手を入れていく方法がお勧め。
とりあえず関連定義の失敗で動かないってことはなくなるからな
0442デフォルトの名無しさん
2007/04/15(日) 10:52:19Toplinkのほうがはるかに上だな
0443デフォルトの名無しさん
2007/04/15(日) 13:58:520444デフォルトの名無しさん
2007/04/15(日) 16:01:27同じようにServletのリファレンス実装がオープンソースになってTomcatになったのを考えると
かなり影響はあるだろうね。
今のところJavaEEはGlassfish一人がち状態ってのもある
もちろん、JavaSEからも使えるようになってるのでGlassfishの上でhibernate使ってもいいけど
0445デフォルトの名無しさん
2007/04/15(日) 16:18:37そだった㌧㌧
hibernateとToplinkのいいトコ鳥になるって話だった希ガス
0446デフォルトの名無しさん
2007/04/15(日) 19:07:02JSF1.2の実装がGlassFishでデフォルトになりつつあるのも大きい
ORマッパー単独で比べるとHibernateの方が多機能だけど、
TopLinkがGlassFishに載ってるというのは大きいな
0447デフォルトの名無しさん
2007/04/15(日) 19:34:450448デフォルトの名無しさん
2007/04/15(日) 20:56:34そういやJBOSSもJSF実装をglassfishのに切り替えたんだっけ。
BEAもやっとJavaEE5だしてきたし、これから加速しそうだ。
肝心のSunが商用JavaEE5鯖が遅れてるのが気になる。
プラットフォーム版はすごい早かったのに。
あとglasshfishがすごい軽いってのも開発者には朗報だな。
10秒以内に起動するEE鯖ってあまりない。
0449デフォルトの名無しさん
2007/04/16(月) 00:29:03JSFもEJBもJPAもJAX-WSもその他諸々もオレにはいらないんだぜ？
0450デフォルトの名無しさん
2007/04/16(月) 00:35:010451デフォルトの名無しさん
2007/04/16(月) 00:54:35放置しておけばよいものを・・・
0452デフォルトの名無しさん
2007/04/16(月) 07:28:43いい加減、竹の子のように出てくる非標準のフレームワークを
組み合わせ続けるのにも疲れてきた
0453デフォルトの名無しさん
2007/04/16(月) 11:26:52標準APIは開発環境が整備されやすいってのも大きいねぇ
いろいろと選べたりするし
0454デフォルトの名無しさん
2007/04/16(月) 18:41:59POHP系にWicket使う程度にとどめておくか。可能なら。
0455デフォルトの名無しさん
2007/04/23(月) 22:46:07その調子だ
0456デフォルトの名無しさん
2007/05/06(日) 16:15:070457デフォルトの名無しさん
2007/05/07(月) 21:58:350458デフォルトの名無しさん
2007/05/08(火) 20:23:070459デフォルトの名無しさん
2007/05/08(火) 21:07:490460デフォルトの名無しさん
2007/05/09(水) 00:58:020461デフォルトの名無しさん
2007/05/09(水) 01:06:120462デフォルトの名無しさん
2007/05/09(水) 13:05:130463デフォルトの名無しさん
2007/05/09(水) 13:10:440464デフォルトの名無しさん
2007/05/09(水) 13:43:020465デフォルトの名無しさん
2007/05/10(木) 23:13:380466デフォルトの名無しさん
2007/06/02(土) 07:56:090467デフォルトの名無しさん
2007/06/02(土) 08:51:46すでに構築されてるデータベースにたいしてO/Rマッピングしようとするﾔｼばかりだから話がややこしくなってるんだな
0468デフォルトの名無しさん
2007/06/02(土) 09:24:420469デフォルトの名無しさん
2007/06/02(土) 10:08:560470デフォルトの名無しさん
2007/06/02(土) 10:24:51意味がわからん
>>469
少なくともHibernateは入っていないようだ
0471デフォルトの名無しさん
2007/06/02(土) 10:54:420472デフォルトの名無しさん
2007/06/02(土) 10:55:07hibernateEntityManagerいれてはじめてそういう動きになる
実際はToplink以外のJPA実装はクソだけどな
0473デフォルトの名無しさん
2007/06/02(土) 10:58:43>>466はまたHibernateについても「Hibernateとか」といって、Hibernateに限定しているわけでもない件
そして、その事が理解できない厨が存在する件
0474デフォルトの名無しさん
2007/06/02(土) 11:02:430475デフォルトの名無しさん
2007/06/02(土) 11:06:400476デフォルトの名無しさん
2007/06/02(土) 11:06:470477デフォルトの名無しさん
2007/06/02(土) 11:10:160478デフォルトの名無しさん
2007/06/02(土) 11:11:290479デフォルトの名無しさん
2007/06/02(土) 11:12:13>>466の解説ではなく最後の行だという事が理解できない厨
0480デフォルトの名無しさん
2007/06/02(土) 11:13:360481デフォルトの名無しさん
2007/06/02(土) 11:16:55その指摘に対して「同じことなんですけど」とだけ返されたってますます意味不明なわけで
0482デフォルトの名無しさん
2007/06/02(土) 11:51:41ORマッピングの話を
や ら な い か ？
0483デフォルトの名無しさん
2007/06/02(土) 12:04:210484デフォルトの名無しさん
2007/06/02(土) 12:09:200485デフォルトの名無しさん
2007/06/02(土) 12:11:31そんなこと無いと思います。
0486デフォルトの名無しさん
2007/06/02(土) 12:13:280487デフォルトの名無しさん
2007/06/02(土) 12:49:06構築済のアプリに導入しようとすると苦労するだけ
新規アプリが望ましいね
0488デフォルトの名無しさん
2007/06/02(土) 12:50:33iBatisのが直感的だと思うのは、単に俺がレガシーなだけかな
0489デフォルトの名無しさん
2007/06/02(土) 13:58:07JPAだとセットされたカラムのみupdateされる
0490デフォルトの名無しさん
2007/06/02(土) 15:06:250491デフォルトの名無しさん
2007/06/23(土) 11:58:400492デフォルトの名無しさん
2007/06/26(火) 22:29:24（＿ ）
（＿＿）
JDBC
■ このスレッドは過去ログ倉庫に格納されています