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

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

ORマッピングはいらない

1 :デフォルトの名無しさん:2006/06/22(木) 11:55:30
あんなもん、レスポンス悪くなるだけ。
SQL直書きがいいに決まってる。

2 :デフォルトの名無しさん:2006/06/22(木) 12:03:52
まあ、同意だな。

複雑なSQLに対処できないし、
簡単なSQLならORマッピング使うまでも無い。
パフォーマンスを考慮したら、邪魔になること間違いない。

コードなかなくても、定義ファイルを作らなきゃいけないから
結局、何も楽にならないし。

データベースのフィールドの値を変数に代入する、
またはその逆の関数程度があれば十分。

3 :デフォルトの名無しさん:2006/06/22(木) 15:30:38
ORマッピングを使うメリットってなんでしょう?


4 :デフォルトの名無しさん:2006/06/22(木) 16:54:53
1. SQLを直書きしなくていい。直書きしないメリットは省略。
2. DBの存在を意識せず、オブジェクトのことだけ考えればいい。

けど現実には>>2が言ってるみたいなことになったりもする。
俺自身はORマッパの是非は要件と使い方によると思うので、いるともいらないとも断言できない。

5 :デフォルトの名無しさん:2006/06/22(木) 17:34:42
必要になるシチュエーションってあんの?

6 :デフォルトの名無しさん:2006/06/22(木) 17:35:12
UPDATEやINSERTもORマッピングって対応してんの?

7 :デフォルトの名無しさん:2006/06/22(木) 17:43:56
UPDATEやINSERTには対応しているが、
ちょっと複雑なJOINには対応していないことが多い。

複雑なSQLかかないのなら、直で書いても手間じゃない。

8 :デフォルトの名無しさん:2006/06/22(木) 23:59:45
Commons DbUtilあたりがちょうどいいなぁ。
中で何やってるか丸わかりで安心だし、
SQL直接指定できて、検索結果はBeanで返ってくる。
コンバータ書けばO-R任意のマッピングもできる。

ただ、リフレクション使うから遅い。
大規模やパフォーマンスにシビアなシステムでは使えない。

9 :デフォルトの名無しさん:2006/06/23(金) 00:44:49
オブジェクトにマッピングするなら、
本格的にオブジェクトにしてくれよ。

たとえば継承やメソッドまで使えるようにする。

10 :デフォルトの名無しさん:2006/06/23(金) 00:57:34
>>9
何を言いたいのか。わけわからん。

11 :デフォルトの名無しさん:2006/06/23(金) 01:01:42
以前どこかのスレでMap最強厨が異常に叩かれていたが、俺は結構Mapもアリだと思う。
最近はDIと絡めて、色々自動生成したりリフレクションに頼ったりしてるが、
トランザクションの最初と最後を強制的に決めてしまう
クロージャや内部クラスのような使い方さえ躾けとけばいいと思う。

12 :デフォルトの名無しさん:2006/06/23(金) 01:37:45
ORMつーより、むしろドメインモデルが何の役に立つのか
分かって無いって感じだな。

13 :デフォルトの名無しさん:2006/06/23(金) 09:48:14
マスメンみたいな簡単なのは
マッパー使って
帳票とかはSQL書きたい。
てなことでS2Daoがしっくりきた。

14 :デフォルトの名無しさん:2006/06/24(土) 14:29:20
はげどう。両方使えるのがいいよな。

15 :デフォルトの名無しさん:2006/06/24(土) 14:31:55
すまん、あげてしまった。

というか、複雑なSQLが書きたい場面って、あんまり多くないとおもうのだがどうよ?
8割9割は簡単なSQLですんで、1割くらいはちょっと複雑になることがある。
それを考えると、すべてをSQL直書きは面倒くさい。
ORマッパーで楽できるところは楽して、SQL手書きでがしがしやりたいところは手書きでやるのがいちばん。

16 :デフォルトの名無しさん:2006/06/24(土) 15:14:17
簡単だが、手間のかかるところを
ORマッピングするわけだが、
どういうこっちゃ?
はぁ?

17 :デフォルトの名無しさん:2006/06/24(土) 15:30:12
>>16
フィールドが200〜300あるのを毎回打ち込むのマンドクセ

18 :デフォルトの名無しさん:2006/06/24(土) 15:55:34
フィールドが三桁もあるのはどっかおかしいのではないかと
思うのは俺だけか?

19 :デフォルトの名無しさん:2006/06/24(土) 15:56:37
訂正:
×: フィールドが三桁も
○: フィールドの個数が三桁も

20 :デフォルトの名無しさん:2006/06/24(土) 15:58:35
書いてから200は多いなと思った
2〜3って読んどいて

21 :デフォルトの名無しさん:2006/06/24(土) 16:04:50
Hibernateしか使ったことないけど、HibernateはSessionから
JDBCのコネクションオブジェクト取れるしね。
ってことは、Hibernate使うときは素のSQL書かせないようには
当然してないと。

Mapに詰めるのは、メンバーが合意してるんだったらいいんじゃね?
って思う。漏れはHibernate使う人だから進んでは合意しない。
getter,setterがあると、eclipseでコード補完効くから、楽だしな。

あと、オブジェクト指向かDB指向かと言われたら、間違いなくDB指向だ。
まあHibernateのObjectの永続化の考えに反するかもしれないが、
RDBには、RDBなりの設計が重要だと考えてるから。
いつなんどき、変態DB屋が現れるかわからんしなw 

22 :デフォルトの名無しさん:2006/06/24(土) 16:09:25
ちょっと屁理屈かもしれんけど、
オブジェクトを使う以上は、フルSQLであろうとなんだろうと、
何らかのORマッピングをやってるわけで、
>>1 の言ってる話は、
なんらかのORマッピングフレームワークによる(半)自動化が、
必要かどうか、という話なんでないの?

23 :デフォルトの名無しさん:2006/06/24(土) 16:25:15
まぁ世の中には流行っているって理由だけで、バッチ処理にORマッピング使う馬鹿がいるからな〜

24 :デフォルトの名無しさん:2006/06/24(土) 16:29:34
    ?
   ∧∧
   (,,゚Д゚)
  /  |
〜OUUつ

25 :デフォルトの名無しさん:2006/06/24(土) 16:58:17
seaserの作者がspringとベンチマーク比較を載せてるけど
結局どっちも遅いな

26 :デフォルトの名無しさん:2006/06/24(土) 17:44:36
>>25
それがORマッピングと何か関係が?

27 :デフォルトの名無しさん:2006/06/26(月) 13:26:32
>>15
>複雑なSQLが書きたい場面って、あんまり多くないとおもうのだがどうよ?

そっかなー、帳票にしろ、更新にしろ単純なSQLはあんまり無いけどなー。
特に更新系のSQLは WHERE を見れば仕様が分かるから
ORマッピング使ってダラダラ書かれると後からおっかけにくい。。

28 :デフォルトの名無しさん:2006/06/27(火) 13:04:08
それは1回のSQL呼び出しですべてを完了させようとするから。
たしかにパフォーマンス考えるとそっちがいいに決まってるんだけど、
パフォーマンス的にシビアでない場合なら簡単なSQLを数回発行するほうが
プログラムが簡単になる。

29 :デフォルトの名無しさん:2006/06/27(火) 15:05:42
UPDATE 売上
SET 請求フラグ = 1
WHERE 売上日 = NOW

みたいなのは

if (obj.UriageDate == Now) {
  obj.SeikyuFlag = 1;
}

これを対象件数分繰り返すの?


30 :デフォルトの名無しさん:2006/06/27(火) 15:47:19
売り上げアクセス dao = コンテナのDAOビルダ.create( 売り上げアクセス.class );
dao.set請求フラグofToday( 1 );

みたいな感じジャマイカ



31 :デフォルトの名無しさん:2006/06/27(火) 17:23:54
更新対象が画面で選択されたものの場合とかどうすんの?

32 :デフォルトの名無しさん:2006/06/27(火) 19:02:08
>>31
対応するインスタンスの状態が変わる→任意のタイミングでDBに反映
って感じかな?俺は元はDB屋なんだけど、ORマッピングに関しては、オブジェクト寄り。
上に出てる多量の行を一気に更新する、ってのはORマッピングに対する反論としてよく出るけど、
オブジェクト(クラス・インスタンス)のほうから設計をすると、そういうのは例外ケースなわけ。
だからSQL直書きでもいいし、ストアドキックでもいいと思ってる。その間、インスタンスは使いづらく
なるけどね。

33 :デフォルトの名無しさん:2006/06/27(火) 21:21:42
mysql+hibernateでトランザクションがロールバックできないってホント?

空気嫁って?

34 :デフォルトの名無しさん:2006/06/28(水) 00:17:57
mysqlってトランザクションサポートしてるの一部のテーブルタイプだけだろ?

35 :デフォルトの名無しさん:2006/06/28(水) 00:52:53
        /つ_∧
  /つ_,∧ 〈( ゚д゚)
  |( ゚д゚) ヽ ⊂ニ)  エェ ── ッ !?
  ヽ__と/ ̄ ̄ ̄/ |
   ̄\/___/ ̄ ̄


36 :デフォルトの名無しさん:2006/06/28(水) 10:02:49
>>35の反応が気になって調べてみた。やっぱInnoDB指定しないと駄目よね。
多分、InnoDB指定しないで「使えねぇ」って言ってるアホと思われ

37 :デフォルトの名無しさん:2006/06/28(水) 15:51:25
>オブジェクト(クラス・インスタンス)のほうから設計をすると、そういうのは例外ケース

まじで??


38 :デフォルトの名無しさん:2006/06/28(水) 19:29:49
まぁ、業務から設計すると帳票とかのデータ構造がまず先に来るから、
仕事では「オブジェクト(クラス・インスタンス)のほうから設計」するのが
まず例外ケースだと思うけどね。

39 :デフォルトの名無しさん:2006/06/28(水) 19:32:11
SQLの代替、進化版じゃなくて、オブジェクトの永続化にDB製品使ってるって話だからさ
SQLとORマッピングの比較じゃなくて、プレーンなファイルを使った場合とDB使った場合での
オブジェクトの永続化のやりやすさ、ってとこを考えないといけない

40 :32:2006/06/28(水) 19:38:46
>>37
たまたま見たのでレス。
マジだよ。ただ、前提条件があるんだが、そこには触れていなかった。

・多量データの更新というのは、データをひとかたまりに見ていれば当然でてくるだろうけど。
 多数のインスタンスという観点で見れば、それに一緒くたに変更をかけるのは、何か間違っ
 てるでしょ?データベースなしと考えてみて。そういうクラス設計には絶対にしないはず。
 する人は、無意識に「データベース」が頭にあるんだと思う。
・で、メンテナンス以外での一括更新ですが、これは単純にはあるクラスで集約するという
 概念になります。データへの変更はなし、ただし特定クラスのインスタンスで集約されている
 状態になる。
・集計などは夜間バッチで集計表に移したり、ストアドプロシージャを利用します。
 得られた結果は元の表とは別のオブジェクトと考えればいい。

抽象的過ぎて、非現実的と思われるでしょうが、データベースにアクセスするんじゃなくて、
あくまでもインスタンスを永続的にストレージに保持する必要があって、たまたまデータベースを
利用するに過ぎないって観点です。そしてデータベースの中で済む処理はすべてお任せ。

上にも書いたけど、クラス・オブジェクト設計して、多量のインスタンスを変更するなんて、
お粗末な設計でしょ。一括ってことは、そこに関連性と法則性があるんだから。

って、いっぱい反論あるんだろうな…繰り返しになりますが、自分はSQL直書きでもストアドでもいいって
立場です。むしろそうやることでドメインモデルから距離を置いたほうがいいよねーって感じ。

41 :デフォルトの名無しさん:2006/06/28(水) 20:14:02
まあ
UPDATE 売上
SET 請求フラグ = 1
WHERE 売上日 = NOW

みたいのは、「請求(乃至イベント)」クラスに1レコード当日日付持たす、でいいわ
日別状態クラスの当日ステータス更新ってかたちでもいい

42 :デフォルトの名無しさん:2006/06/29(木) 10:46:33
データ更新用オブジェクトを作ればいいじゃないか

43 :デフォルトの名無しさん:2006/06/29(木) 17:43:38
意味がわからんが、部分集合に対するupdate文を発行するオブジェクトって意味だとすると、
メモリ上の各レコードのインスタンスとの整合性保持するのが困難

44 :デフォルトの名無しさん:2006/06/29(木) 19:17:29
データを大量にインスタンスとして持とうとすると、一挙にややこしくなるねえ。

45 :デフォルトの名無しさん:2006/06/29(木) 22:37:48
>>38
帳票とかのデータ構造が先に来るってのは、
DB屋の設計手法としても間違ってると思うのだが。

Sヨお得意の画面/帳票まんまな糞DBじゃんw

46 :デフォルトの名無しさん:2006/06/30(金) 01:59:28
帳票(現在)→DBエンティティ→帳票(改修)

47 :デフォルトの名無しさん:2006/07/01(土) 21:58:23
>>29
>これを対象件数分繰り返すの?
ORマッピングだけをつかうなら、そういうことになる。
あとはdeleteのときも、件数分delete文を発行する。
もちろんこれは効率が悪いけど、それで速度的に問題ない場面ならORマッピングをそのまま使う。
問題ある場合だけSQLをがしがし書く。
だからORマッピングだけで完結させるのは難しいし、そんなことにはこだわらないほうがいい。

>>40
>多数のインスタンスという観点で見れば、それに一緒くたに変更をかけるのは、何か間違っ
>てるでしょ?データベースなしと考えてみて。そういうクラス設計には絶対にしないはず。
そんなばかな。業務システムではしょっちゅうあるけど。なぜこんなことを言い切れるのか不思議。

48 :デフォルトの名無しさん:2006/07/02(日) 09:55:24
とりあえずHibernate+Springは俺には無理だったな
セッションやらキャッシュやら自動トランザクションやら訳判らんし、データ更新してもTomcat再起動すると元に戻ってたりと、
ORマッパーが裏で何やっているか完全に把握している人間がいないとダメだわ

まぁ俺が不勉強なだけだけど、
普通にJDBC直書きでトランザクション制御はTemplateMethodパターンの方が遥かにわかりやすかった

49 :デフォルトの名無しさん:2006/07/02(日) 10:21:17
>まぁ俺が不勉強なだけだけど、
自分でわかってんじゃん。
新しい物を覚える能力に欠けていると自覚するなら
この業界でやっていくのは難しいよ。
オブジェクト指向が理解できないCOBOLオヤジと一緒。
早く別の道を探した方が良さそうだね。



50 :デフォルトの名無しさん:2006/07/02(日) 10:38:46
>>48
そんなあなたにS2DAOをお勧めする
設定ファイルもシンプルで簡単だし、サンプルもわかりやすくてマジ最高

51 :デフォルトの名無しさん:2006/07/02(日) 11:33:46
結論:ORマッピングはいらないと言っている連中はオブジェクト指向が理解できないCOBOLオヤジと一緒。

52 :デフォルトの名無しさん:2006/07/02(日) 14:04:16
select * from table
でとってきた奴はO/Rマッピングオブジェクトに入れた方が
その後ガシャガシャやるのに便利じゃないか。
ただHibernateみたいにupdateでO/Rマッピングオブジェクト渡して
全カラムupdateするのは嫌だな。
うっかり変更する必要がないプロパティ変更しちゃってたら大変だ。
なのでupdateは、必要なカラムだけupdateするSQL呼び出しをDAOを作る。


53 :デフォルトの名無しさん:2006/07/02(日) 14:14:27
>>52
>ただHibernateみたいにupdateでO/Rマッピングオブジェクト渡して
>全カラムupdateするのは嫌だな。

無知。使いこなせていない奴が文句言うな。


54 :デフォルトの名無しさん:2006/07/02(日) 14:28:56
>>53
一生懸命勉強しないと使いこなせないものってダメだと思う、Hibernateがそうなのかどうかは
別として。

55 :デフォルトの名無しさん:2006/07/02(日) 14:34:44
>>54
ダメなものかどうかを自分で決められるのなら、そう言ってろ。
おまい自身が「一生懸命勉強しないと」と感じるかどうかが基準か?

ダメだどうのと言っている奴がダメだ。
この仕事をしている限り、デファクトスタンダードは避けて通れないんだよ。


56 :デフォルトの名無しさん:2006/07/02(日) 14:39:09
今から勉強するとしたらejb3かねぇ

57 :デフォルトの名無しさん:2006/07/02(日) 14:45:19
Hibernateを使ってたらわかると思うけど、O/Rマッパーが提供するのは
「SQL記述の冗長な部分のみを自動化する」機能であって
システムとしてはよりDBに依存した形になる。
DBの存在を隠蔽するとか、SQL的な記述を隠蔽するとかいう説明は誤り
作成されるSQLを完全に理解できるくらいでないと、O/Rマッパーを使うのは難しい

SELECT文でカラムをJOINしたテーブル毎に全部書いたり、結合の度にJOIN句を書いたり
INSERTやUPDATEを書く処理は、どれもテーブル定義さえ知っていたら自動化できる処理だから
そこら辺はO/Rマッパーに任せる。
逆に検索条件や副問い合わせを駆使するようなSELECT文は、SQLだからこその機能だからSQL寄りに書く。
Hibernateなら、HQLを使えばSQLとほぼ同レベルのことが書ける。
HQLではFROM句での副問い合わせやUNIONが書けないのは不満だが、そんなときはSQLQueryを使えばいい

58 :54:2006/07/02(日) 16:16:29
>>55
いやー、おまいみたいな優秀な奴だけを集めてプロジェクトを進めるのが難しいという現実がある以上、
一生懸命勉強しなくても使えるものを採用しないとダメだと思うけどねぇ。

ダメだどうのと言っている奴がダメなのは同意するけど、だからといってそういう奴でも
開発メンバーに加えざるをえない状況もあるわけで。
ところでHibernateはO/Rマッピングのデファクトとまでいっちゃっていいものなんですかね?


59 :デフォルトの名無しさん:2006/07/02(日) 16:35:10
>>58
>>55が優秀かどうかもわからないのに、口だけ調子いいこと言ってる奴もダメだな。
メンバー全員がHibernateに精通していないと、という前提になっているところもダメ。
設計やフレームワークの使い方を間違っている可能性大。

60 :デフォルトの名無しさん:2006/07/02(日) 19:31:55
全員がHibernateに精通している必要なんてないだろ。
一人だけ詳しい奴がいれば、あとの連中の生産性を最大化することが
できる。
むしろそれがORMの最大の狙いで、SQLを使ったやり方だと、メンバー
全員がDB設計SQL設計に精通している必要が出てくる。

61 :デフォルトの名無しさん:2006/07/02(日) 21:11:10
>>59
「優秀かどうかもわからないのに、口だけ調子いいこと言ってる」
ただのイヤミだろ。

「メンバー全員がHibernateに精通していないと」という前提をしてないからこそ
「一生懸命勉強しないと使いこなせないものってダメだと思う」という書き込みがあるわけだが。

62 :デフォルトの名無しさん:2006/07/02(日) 21:26:59
>>61
>「メンバー全員がHibernateに精通していないと」という前提をしてないからこそ
>「一生懸命勉強しないと使いこなせないものってダメだと思う」という書き込みがあるわけだが。

矛盾してないか?

メンバー全員がHibernateに精通していることが前提でなければ、
メンバーの一部に使いこなせる奴がいれば充分だろ?
メンバー全員が>>55みたいに優秀な奴である必要はないんだよ。


63 :デフォルトの名無しさん:2006/07/03(月) 00:27:25
この先生きのるのはEJB3.0、Hibernate、S2Daoどれ?

64 :デフォルトの名無しさん:2006/07/03(月) 00:32:20
HibernateはJPAに対応したし、S2DaoもJPAに対応する(Kuina)予定らしい

65 :デフォルトの名無しさん:2006/07/04(火) 13:24:50
O/R マッピングを有難がる奴ってのは
>>52
>select * from table
こんなのばっかりなのか?

66 :デフォルトの名無しさん:2006/07/05(水) 01:13:27
シンプルが一番

67 :デフォルトの名無しさん:2006/07/08(土) 01:01:09
シンプルってよく言うけど、どういう状態がシンプルなのか
理解している奴は少ない。

シンプルに実装しました、とかベタで書きましたとかいって
for文の5段ネストとかそんな感じのソースが出てくる。

68 :デフォルトの名無しさん:2006/07/08(土) 16:41:11
ORマッピングって今いち楽だねって実感が無いね。
楽するためにプログラミングしてるはずなのに、全然楽じゃない。

XMLなんて醜くて遅くなるだけだし。

一人の詳しい香具師が居ればいいってのもいまいち。
その一人が逃亡した時点で終わるし、その一人の給料だけ高くすると不満が出るし、他がやる気無くすし、その一人のために他の香具師が低い賃金でこき使われることに成る。
詳しくなくても簡単に使えるORマッパが求められてると思う。

69 :デフォルトの名無しさん:2006/07/08(土) 16:52:19
>>68
使ってみたORマッパーとその問題点を具体的にきぼん。
> XMLなんて醜くて遅くなるだけだし。
だけでは根拠が弱い(XMLを使うと遅くなるわけではないので)。

70 :デフォルトの名無しさん:2006/07/08(土) 17:32:22
XML に何の関係が?

71 :デフォルトの名無しさん:2006/07/08(土) 17:38:47
XMLを使用しないとなるとRoRのActiveRecordとか?

この辺りは使ったことないけど、どうなんだろう?

72 :デフォルトの名無しさん:2006/07/08(土) 20:40:12
書き方が変わるだけで楽にはならない。

73 :デフォルトの名無しさん:2006/07/08(土) 20:45:29
XMLのマッピングファイルで遅くなるってのは
実装速度じゃなくて開発効率の話しかな?

マッピングファイルを手書きしていたらORMのメリットはかなり低下するだろうな。
ここは、現実的にはMiddlegenとかXDocletを使って自動生成する部分だろう。

手書きめんどくさいと言っている人は雑誌やWebのサンプルに沿って
ちょっとモノを作ってみただけで判断してないか?

>>68 はフレームワークの使い方やプロジェクトでの役割分担を根本的にわかっていない希ガス

74 :デフォルトの名無しさん:2006/07/10(月) 00:39:47
ORMのメリットがわかんねー云々以前に、ドメインモデルを使ってるかどうかを
問いたい。

75 :デフォルトの名無しさん:2006/07/11(火) 23:41:51
おれ、ドメインモデルがよくわかんねぇ。

いっつも

http://(domain)/hogehoge/mogemoge.jpg

↑の意味のドメインが頭に浮かんできて、何の事やらサッパリわからんくなる。

76 :デフォルトの名無しさん:2006/07/12(水) 06:39:49
http://(domain)/

↑これ自体間違いだしな

77 :デフォルトの名無しさん:2006/07/14(金) 01:15:07
解説頼む

78 :デフォルトの名無しさん:2006/07/14(金) 13:39:42
http://

↑これ自体間違いだしな

79 :デフォルトの名無しさん:2006/07/14(金) 22:38:17
じゃ
mailto:sage@(domain)
ってのは?

80 :デフォルトの名無しさん:2006/07/15(土) 09:25:47
おまえ、もしかして知ったかしてねぇ?>>76,>>78
どうなんだよ、オラオラ

81 :デフォルトの名無しさん:2006/07/15(土) 09:35:52
http://(domain)/
については、間違いだとは判るが
http:// 自体のどこが間違っているのかは俺には判らん。

http://www.yahoo.co.jp/ の場合、
インターネットドメインは yahoo.co.jp であって www.yahoo.co.jp ではない。
http://203.216.247.249/ だったらインターネットドメインはどこにも含まれない。


82 :デフォルトの名無しさん:2006/07/15(土) 09:36:44
つまり、 http://(domain)/ の(domain)はドメインではなく、ホストを表す文字列だということ。

83 :デフォルトの名無しさん:2006/07/15(土) 09:50:55
ホストを表す文字列に (domain) というのはおかしいという話では?

84 :デフォルトの名無しさん:2006/07/15(土) 11:01:55
OK,(host)と(domain)の違いはなんとなくわかった。
(host)からwww1とかwwwとか、ftpを取り除けば(domain)になるってことだな。

で、結局、ドメインモデルと(domain)では、ドメインって別のものを指してるよな?

そこら辺がおれにはよく分からんのだよ。

では、そこを起点に議論の再開を求む。

85 :デフォルトの名無しさん:2006/07/15(土) 11:15:15
domainといっても色々種類があるが、最も一般的なのは
代数的かつ整合完備な半順序集合bcdomだろう。
bcdomは関数構成子に関して閉じており、圏としてみた場合
cccをなす

86 :デフォルトの名無しさん:2006/07/15(土) 11:32:59
ドメインというのは大雑把に言って(何かで区切られた)「領域」。
DNS におけるドメインというのは、ネットワークにおける(管理上)の「領域」、
企業や部門などの管理者が置かれる単位。

データモデリングにおけるドメインは、データにおける「領域」、
つまり、対象領域とする業務やアプリケーションに含まれる(モデル化すべき)
データの集合、ないし、データが存在する対象領域そのもの。


87 :デフォルトの名無しさん:2006/07/17(月) 04:05:39
まずは英和辞書を引いてから
考えてみようって話だな。

カタカナでドメインだと確かに
この業界、初学者にはまぎらわしいですな。

88 :87:2006/07/17(月) 04:22:52
それと、「領域」ってのも間違いじゃないんだろうけど
どうも物理的な場所のイメージが強くてよくわからん。
「問題領域」なんて訳がよく使われるけど、
なんか頑張って考えたのが伝わってきちゃっていかん。

「うちはA社とはドメインが違うから競合しません」
みたいな言い方もよく聞く。

そうすると、「業界」みたいな意味もあるように思える。
正確には粒度はもっと小さいんだろうけど。

てことは、ドメインモデルって
「業界用語」って事でいいんじゃないの?
ただの業界用語集ってだけでなく、
構造まで表現したもの、てなかんじ。

寝ようと思って布団に入ったら思いついたから
また書いた。



89 :デフォルトの名無しさん:2006/07/17(月) 10:17:57
縄張り

90 :デフォルトの名無しさん:2006/07/17(月) 10:40:47
>ドメインモデルって「業界用語」って事でいいんじゃないの?

ちがうだろ。


91 :87:2006/07/17(月) 16:46:27
うーんやっぱちがうか。

92 :デフォルトの名無しさん:2006/07/17(月) 17:31:01
普通に、解決しようとしている対象をちゃんとモデル化しているかってことだろ
ドメインという言葉よりモデルの中身の方が大事だよね

93 :デフォルトの名無しさん:2006/07/18(火) 13:57:23
もう、メンドイ

94 :デフォルトの名無しさん:2006/07/18(火) 15:38:56
恕面モデル

95 :デフォルトの名無しさん:2006/07/18(火) 23:36:57
>>93
もちょっとふんばってイドメ

96 :デフォルトの名無しさん:2006/07/18(火) 23:42:04
ドメインメンドイイドメンってことか、やるねぇ

97 :デフォルトの名無しさん:2006/07/19(水) 02:17:55
メイドインドメイン

98 :デフォルトの名無しさん:2006/07/19(水) 10:27:12
>>97
これがトドメだな

99 :デフォルトの名無しさん:2006/07/19(水) 11:10:26
メイドインインド

100 :デフォルトの名無しさん:2006/07/28(金) 19:08:27
なんかよくわからんが
O/Rマッピングに妙に肩入れしてるのはJAVA界隈の人だけだと言うことは分かった。

101 :デフォルトの名無しさん:2006/07/29(土) 14:29:49
まあ、毎回スキーマーとプログラムを見比べて、
SELECT 文の出力を、変数に代入するコードを書くことを

「あたりまえ」

だと思って何の不満も感じてないなら、 OR マッピングなんて必要ないわな。


102 :デフォルトの名無しさん:2006/07/29(土) 22:45:35
ORマッピングは
SELECT文の出力を変数に代入するコードを書かなくてもいい代わりに、
SELECT文の出力を変数に代入する設定ファイルを書かなくてはいけない。
本質的には何も変わらない。

103 :デフォルトの名無しさん:2006/07/29(土) 22:57:44
>>102
設定ファイルを手書きするバカなんていないけどな。

104 :デフォルトの名無しさん:2006/07/29(土) 23:11:59
class Hoge < ActiveRecord::Base
end

で完了だけどな

105 :デフォルトの名無しさん:2006/07/31(月) 09:45:01
外部結合と抽出条件、グループ化を伴うちょいと複雑なSQLと、O/Rマッピングで
それと同等のSQLを吐くプログラムコードを見せて欲しい。

>>101でもいいよ。

106 :デフォルトの名無しさん:2006/07/31(月) 09:59:25
いまだにこういうこと言う奴がいるのか。


107 :デフォルトの名無しさん:2006/07/31(月) 10:48:49
SQLでJOINするよりも、
ORMがさらっとやってくれるCacheとLazyLoadingの方が
パフォーマンス上がる場合が多いよ。

自力でCacheしろという意見はきかん。

108 :デフォルトの名無しさん:2006/07/31(月) 13:34:07
>101
>SELECT 文の出力を、変数に代入するコードを書くことを

そんなことしないってw

109 :デフォルトの名無しさん:2006/07/31(月) 15:24:39
>>108
お前がそうしないのは勝手だが
お前の事情など知った事ではない。

110 :デフォルトの名無しさん:2006/07/31(月) 15:34:20
今時SELECTの結果をいちいち変数に入れなければいけないような実装は
ないんじゃないのか? API直接叩くなら別だけど。

>>101がどういうつもりで言ってるのか知らないけど。

111 :デフォルトの名無しさん:2006/07/31(月) 21:01:13
いや、SELECT 文の結果を変数に入れないなら、
どうやってSQL以外のプログラムからDBにアクセスするんだ。


112 :デフォルトの名無しさん:2006/07/31(月) 23:08:40
馬鹿だな、みんなwww
変数に入れないって事は

M a p に 入 れ る

って事じゃないか。

113 :デフォルトの名無しさん:2006/07/31(月) 23:18:46
Map厨キタ━━━━━━(゚∀゚)━━━━━━ !!

114 :デフォルトの名無しさん:2006/07/31(月) 23:21:44
>>112
おおー久々のネタだ!!!
よく覚えてたなw

115 :デフォルトの名無しさん:2006/08/01(火) 14:05:45
>111
直接レコードセットのフィールド参照すりゃいいじゃん

116 :デフォルトの名無しさん:2006/08/02(水) 00:24:50
>>115
だよな。

117 :デフォルトの名無しさん:2006/08/03(木) 15:10:14
いちいち変数に代入したがる奴っているよな。

118 :デフォルトの名無しさん:2006/08/03(木) 15:21:03
それはORMとどう違うのだ?
それとも Javaで言うと ResultSet をViewから直接参照するのか?
非常識な設計だな。

119 :デフォルトの名無しさん:2006/08/03(木) 17:49:55
>それはORMとどう違うのだ?
>それはORMとどう違うのだ?

120 :デフォルトの名無しさん:2006/08/03(木) 19:27:19
>とどう違うのだ?
そのコードを、作成するたび、変更があるたび、
いちいち人間さまが書く必要があるかないか。


121 :デフォルトの名無しさん:2006/08/03(木) 19:47:01
>>120
つまり、ViewでResultSetを直接参照してるってこと?
データをオブジェクトとして扱うという発想がないってこと?
.NETってWebでもそんなことするの?

122 :デフォルトの名無しさん:2006/08/03(木) 19:53:34
>>121
っていうか、なんでそこでView がでてくるのかわけがわからん。
仮にいちいち書くとしても、データアクセス層の話だぞ。

123 :デフォルトの名無しさん:2006/08/03(木) 19:59:47
>>122
ん?じゃあ、最終的にはどこかで取り出したデータを
オブジェクトに入れ替えるコードは書くわけ?


124 :デフォルトの名無しさん:2006/08/03(木) 20:04:41
>>123
>取り出したデータをオブジェクトに入れ替える

だから、それがORマッパの機能で、それ(ORマッパ)を使わない場合は、
そのコードを人間がいちいち手で書くことになる、
というのが、>>120 の文意だよ。

125 :デフォルトの名無しさん:2006/08/03(木) 20:12:13
>>124
ああ、そういうことね。>>120 を読み違えてた。
ResultSetを直接扱えば、変更があってもマッピング定義を
変えなくていいじゃん、という非常識な意見だと思ったよ。

じゃあ、結局ORMイラネって言ってるやつは
いちいち手書きしてるってことか。
なんと非効率なことか・・・・
アホか。

126 :デフォルトの名無しさん:2006/08/03(木) 23:12:32
>>121でいきなり.NETが出てくる理由がわからん。信者か?

127 :デフォルトの名無しさん:2006/08/04(金) 11:49:37
>いちいち手書きしてるってことか。

なにを?

128 :デフォルトの名無しさん:2006/08/04(金) 12:23:00
ループしてきた?

129 :デフォルトの名無しさん:2006/08/04(金) 17:15:53
>>105でも聞いたけど、例を出してその優位性を見せてくれれば一発で
片が付く議論なのに、なんで出してくれないの?

130 :デフォルトの名無しさん:2006/08/04(金) 17:29:50
>>129
そもそも前提が間違ってるから。
今時おまいみたいなこと言う奴まだいるんだなw


131 :デフォルトの名無しさん:2006/08/04(金) 17:31:44
>>130
で、例は? また出さずにグダグダやるわけ?

132 :デフォルトの名無しさん:2006/08/04(金) 17:48:35
前提が間違ってると言われてるのに、例は?とかまだ言ってるのか。
どうしても何を言われてもオブジェクト指向を理解できないコボラーのように頭ガチガチなんだなw

133 :デフォルトの名無しさん:2006/08/04(金) 18:19:28
まあ前提がおかしいのは >>1 から既にそうだしな。

134 :デフォルトの名無しさん:2006/08/04(金) 18:31:11
>>132
前提とかその辺はどうでもいいのよ。
オブジェクト指向はかくあるべき云々なんて教条的で頭ガチガチ(笑)な話じゃなくて
単純にO/Rマッピングの利点の話。

単にオブジェクト指向ってだけならデータセットレベルでもオブジェクト指向してるワケで
O/Rマッピングを採用することでどんな具合に楽になるの? ってことが知りたいわけ。

だから>>105に挙げた例を出してくれって言ってる。

135 :デフォルトの名無しさん:2006/08/04(金) 18:46:28
>>134
>オブジェクト指向はかくあるべき云々なんて教条的で頭ガチガチ(笑)な話じゃなくて
ホントにわかってないなw
そんな話をしてるんじゃないだろ?

オブジェクトを永続化するのになぜ>>105のような例が出てくるのかまったく理解できない。


136 :デフォルトの名無しさん:2006/08/04(金) 18:48:54
>>105を前提に例を求める時点でORMの使い方をわかってないってこと。
そんな奴が無理矢理使っても失敗するからやめとけ。

137 :デフォルトの名無しさん:2006/08/04(金) 19:18:13
>>135
オブジェクトの永続化なんて言っても、その永続化の先にあるのはあくまで
SQL完備のRDBMSが前提でしょ?

>>105の何がおかしいわけ?

138 :デフォルトの名無しさん:2006/08/04(金) 19:32:13
>>105

1. 関連するtableの全recordをobjectにmapping
2. 1で生成したobjectの集合に対して、好きな方法で必要なobjectを抽出する

139 :デフォルトの名無しさん:2006/08/04(金) 20:04:38
オブジェクトの永続化という視点でモデリングをして
どうしたら>>105みたいな状況になるんだかw
設計とモデリングがヤバいだろ。


140 :デフォルトの名無しさん:2006/08/04(金) 20:27:46
ちゃんと説明を行わないからだよ。
ORMの利点と欠点を説明すれば納得するはずだ。

そもそもはオブジェクトの世界とデータレコードの世界の
インピーダンスミスマッチの解消のための技術。
そのため、相互マッピングというオーバーヘッドが発生するのは
デメリットといえる。
しかしその代わり、オブジェクトの世界における取り扱いの
柔軟性というメリットを享受できる。
その点に魅力を感じないのであれば、その人にはORMは必要なし。

141 :デフォルトの名無しさん:2006/08/04(金) 20:38:42
>>138
関連テーブルにレコードが100万個あったら100万個オブジェクトを作るのか?
最悪だな。

142 :デフォルトの名無しさん:2006/08/04(金) 20:46:10
>>141
そんなわけないだろ。アホか。
Lazy Loading ってのがあるんだよ。

143 :デフォルトの名無しさん:2006/08/04(金) 20:49:32
だがjoinしようと思ったら結局全レコード分のオブジェクトを作る羽目になる…

144 :デフォルトの名無しさん:2006/08/04(金) 20:54:27
臨機応変にVIEWとか使えばいいんじゃね?
ORM使うのが目的じゃないし、ただの手段にこだわってもな。。

145 :デフォルトの名無しさん:2006/08/04(金) 21:10:00
>>144
正解。

146 :デフォルトの名無しさん:2006/08/04(金) 21:59:39
>>143
げー、なにそれ。

裏でSQL作って投げるんじゃなくて、全レコード引っ張ってきて自前で総当たりするのか…。
そういう代物だとは思わなかった。

147 :デフォルトの名無しさん:2006/08/04(金) 22:10:32
んなわけない

148 :デフォルトの名無しさん:2006/08/04(金) 22:37:11
>>129
オートマ市販車で、ワークスマシンと同等のタイムを出してみろ。
といっているのと変わらん。無意味な質問だ。

149 :デフォルトの名無しさん:2006/08/04(金) 22:57:43
>>148
誰も実行速度の話なんてしてないじゃん。

150 :デフォルトの名無しさん:2006/08/04(金) 23:24:33
>>146
ORMがそんなに便利になれるわけない

151 :デフォルトの名無しさん:2006/08/04(金) 23:59:52
>>149
うん、君を除いては「誰も」していないね。


152 :デフォルトの名無しさん:2006/08/05(土) 01:21:56
>>105
JPQLがそれら全てに対応してることからわかるように
検索処理はSQL的な記述を最大限に利用するのが正解
O/Rマッピングが力を発揮するのは、データを取得した後の登録・更新処理
Hibernateの場合、Beanに値をつめてツールのメソッドにわたせばINSERT文が発行されるし
SELECT文で取得したBeanの値を変更すれば、トランザクション終了時に自動的にUPDATE文が発行される。
これらのINERT・UPDATE文はJDBCのバッチUPDATEを利用する為、ある程度のパフォーマンスも期待できる。
また、このとき排他処理が自動的に実行される。
Webアプリなどのロングトランザクション管理が必要な場合は必須といえるツールだと思う

データのBeanへのマッピングも便利だが、それは昔からDbUtilsなどで実現していた機能だからな

>>143
ツールで自動作成すればいい。外部キー制約をつけていれば、クラス間の関連定義まで自動でやってくれる

153 :デフォルトの名無しさん:2006/08/05(土) 23:28:02
ぶっちゃけマッピング面倒だ。
自動化出来ないのか?

154 :デフォルトの名無しさん:2006/08/06(日) 02:28:23
>>153
できるよ
ってか、するのが当然・普通・あたりまえ。


155 :デフォルトの名無しさん:2006/08/06(日) 02:35:34
ORMうんぬんよりも
ここにいる人達は正直イタイと思った。

まずは日本語をw

156 :デフォルトの名無しさん:2006/08/06(日) 09:51:56
日本語をマッピングするのか?

157 :デフォルトの名無しさん:2006/08/06(日) 10:41:30
ぶっちゃけ脳内→日本語マッピング面倒だ。
自動化出来ないのか?

158 :デフォルトの名無しさん:2006/08/06(日) 10:44:04
>>157
できるよ
ってか、するのが人として当然・普通・あたりまえ。

159 :デフォルトの名無しさん:2006/08/06(日) 10:52:37
Java以外ではろくなORマッピングが存在しない。
あっても、逆に手間がかかる。

160 :デフォルトの名無しさん:2006/08/06(日) 13:09:24
Javaが一番SQL分からない馬鹿による被害が甚大なんだろ

161 :デフォルトの名無しさん:2006/08/06(日) 13:15:40
>>160
シッタカ乙。
ORMの役割・メリットはそこじゃないっつーの。

162 :デフォルトの名無しさん:2006/08/06(日) 14:29:52
>>157
PG云々以前の問題だなw


163 :デフォルトの名無しさん:2006/08/06(日) 17:01:51
>>161
> ORMの役割・メリットはそこじゃないっつーの。
じゃあどこさ?

164 :デフォルトの名無しさん:2006/08/06(日) 17:16:19
エンティティとデータの関係を言語ソースの外に出せることだろ

165 :デフォルトの名無しさん:2006/08/06(日) 18:11:45
そもそもPGって日本語不自由な香具師が多いよね。
ソースで会話したほうが速いことが多杉!

166 :デフォルトの名無しさん:2006/08/06(日) 19:27:07
ORMなんて小ざかしい事せずに、OODBのほうが良いような気がしてきた。

167 :デフォルトの名無しさん:2006/08/06(日) 20:13:48
>>163
SQLを知ってる・知らないではなく、
SQLとオブジェクトのマッピング作業をフレームワークがやってくれる点。

168 :デフォルトの名無しさん:2006/08/06(日) 23:34:16
>>163
ORMはSQLを知っていることが利用の最低条件
目的は、SQL記述から冗長な部分を省いて永続化処理の生産性を上げること

169 :デフォルトの名無しさん:2006/08/07(月) 00:28:57
【ORMの役割・メリット】
・エンティティとデータの関係を言語ソースの外に出せること(>164)
・SQLとオブジェクトのマッピング作業をフレームワークがやってくれる(>167)
・SQL記述から冗長な部分を省いて永続化処理の生産性を上げる(>168)

色んな表現があるが、同じことを意味している?

170 :デフォルトの名無しさん:2006/08/07(月) 00:55:58
てか日本語じゃ良く分からんから
ソースで示してくれんかの?

171 :デフォルトの名無しさん:2006/08/07(月) 01:14:48
>>170
ResultSet 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"));
・・・

上記のような単純で退屈でコピペミスしやすく、
しかし大量に書かなければ行けないような処理を、
テーブル毎・検索処理毎に書かなくて良い。
上記のコードを手書きするとカラム名やカラムの型を間違える可能性もあるが
マッピング定義ファイルを自動生成すればカラム名やカラムの型を間違えることもない。
カラムの追加変更があっても、このようなコードだと影響箇所を修正するのは骨が折れるが
マッピング定義ファイルを自動生成すればかなりの省力化が可能。


172 :デフォルトの名無しさん:2006/08/07(月) 23:13:03
テーブル構造をオブジェクトにマッピングするツール ×
オブジェクトをテーブル構造にマッピングするツール ○

RDBMSとオブジェクト指向言語との親和性を高めるツール ×
オブジェクトを永続化する先の入れ物としてRDBMSを使うためのツール ○

既存のテーブル構造にORMを適用する事も自動化ツールのサポートで容易 ×
ORMを使っていない環境で構築されたテーブル構造への適用は困難 ○

この辺りを理解してないORM信者も多すぎる。
所詮はラッピングツールであり、余程単純なシステムでもない限りSQL直書きは避けられない。
ここを勘違いすると、JAVAコードをすっきりさせるために一貫性の無いVIEWやストアドを大量に作成して
DBの中を阿鼻叫喚地獄絵図にしてしまうという本末転倒をやらかす。


173 :デフォルトの名無しさん:2006/08/07(月) 23:18:47
まあ、DBの中が阿鼻叫喚地獄絵図になってしまうようなやりかたで、
Java コードだけはすっきりしてるなんてありえないけどな。

174 :デフォルトの名無しさん:2006/08/08(火) 01:04:35
>>172
>ORMを使っていない環境で構築されたテーブル構造への適用は困難 ○

別に困難じゃなかったぞ
重要なのは適用検討しているテーブル構造の正規化の度合い
主キー無し、外部キー無し、結合条件がDBの制約では決まらないetcな構造だったら諦めるべきだが
普通に正規化されたテーブルなら適用は容易

ORMって結局DB側に寄ったツールであることを勘違いしてはいけない
SQL直書きサポート必須は同意。最近のツールはどれもサポートしてるけど

175 :デフォルトの名無しさん:2006/08/08(火) 22:37:39
なんでもかんでもSQLでやって、UIだけプログラムで作れば


176 :デフォルトの名無しさん:2006/08/09(水) 09:35:08
作れば・・・

177 :デフォルトの名無しさん:2006/08/09(水) 09:45:51
>>175
なんでもかんでもSQLでやって、UIだけプログラムで作れば、
UI部分のプログラムにはカラム名を指定して値を一つ一つ取り出す記述や
入力値をSQLに埋め込む処理を大量に書くことになる・・・と。

178 :デフォルトの名無しさん:2006/08/09(水) 13:38:46
どんな開発ツールを使ったそんなへっぽこな発想になるんだ

179 :デフォルトの名無しさん:2006/08/11(金) 21:52:50
なんでもかんでもVBでやって、ばぐった時だけ外注で作れば

180 :デフォルトの名無しさん:2006/08/13(日) 14:35:29
ぐらーぐらとにえる♪

181 :デフォルトの名無しさん:2006/08/16(水) 18:20:02
db4oならORマッピング不要ですね

182 :デフォルトの名無しさん:2006/08/17(木) 06:07:00
もうDLinqでいいじゃん

183 :デフォルトの名無しさん:2006/08/19(土) 23:01:51
>>181
とりあえず本1冊読んでみたけど、組み込み向けじゃん。

184 :デフォルトの名無しさん:2006/08/20(日) 00:12:50
>>183
別に組み込み用では無いが。

185 :デフォルトの名無しさん:2006/08/20(日) 16:12:06
RDBMSの代用には向かない気がするけど。

186 :デフォルトの名無しさん:2006/08/20(日) 23:25:44
OODBをRDBMSの代用として考える方がおかしい気がするけど。

187 :デフォルトの名無しさん:2006/08/21(月) 21:09:59
db4oの中の人はリレーショナルの代用になるって言ってる。

実際のところ、どうかは知らんが。

188 :デフォルトの名無しさん:2006/10/07(土) 04:11:26
Hibernate最強でしょう。
いまどきJavaの世界にSQL持ち込んでる糞は氏んでよしと。

189 :デフォルトの名無しさん:2006/10/07(土) 08:32:52
Hibernate ってそこまで(SQLを一切使わなくて良くなるほど)万能なものとは
思えんのだけど。

190 :デフォルトの名無しさん:2006/10/07(土) 09:18:59
Map最強説唱える奴にはそう見られても仕方が無い

191 :デフォルトの名無しさん:2006/10/07(土) 09:51:14
    ∧∧
    (,,゚Д゚)    ヨイショ....
   / つ〜⌒ヽ
   ( (';; _, ...,,)
   ∪,)....´;;;,,,..(ヽ
    (::::::ノ⌒)_ヽ)
      ̄   
   ∩⌒>⌒ヽ ゴソゴソ
  /(';; _, ...,,)
  ( ,)...´;;;,,,..(ヽ
  U(::::::ノ⌒)_ヽ)

   ∧∧
  /(*゚Д゚) オフトンサイコー♪
  / :::У~ヽ
 (__ノ、__)

  _  カタカタカタ
 .//|.|   /'∧   
 | |..|.|  (Д゚,ノ⌒ヽ マッピングサイキョー♪
  ̄ll ]-、と/~ ::ノ:::)
  ̄ ̄ ̄|(_.( :: ,:_)

192 :デフォルトの名無しさん:2006/10/07(土) 16:46:05
個人で作ってような実験アプリとか趣味アプリだったらdb4oで良いんじゃねーか?

今はtomcat + hibernate + postgres だけどそのうち時間があったらtomcat + db4oに変えてみる。
どれだけ生産性があがるかレポートしますね。

193 :デフォルトの名無しさん:2006/10/07(土) 23:44:02
db4o ってリファクタリングに追従できんの?

194 :デフォルトの名無しさん:2006/10/08(日) 02:48:10
>>188
Hibernate in Actionを一度読んでみるべき
「HibernateはSQLを熟知した開発者こそが使うべきツールである」
と開発者自身がはっきり宣言している

195 :デフォルトの名無しさん:2006/10/08(日) 04:06:59
>>193
知らないけど、既存データを捨てていいなら、自動じゃないの?


196 :デフォルトの名無しさん:2006/10/08(日) 09:25:12
既存データの扱いが問題なんだよなー

1.SQLで以降処理を作る
2.変更後のDBは別のDBとして作り、マッピングベースで以降プログラムを作る
3.その他

どうするのがいちばんいいのか。

197 :188:2006/10/08(日) 10:43:46
>>194
はい、読んでます。

SQLの知識は必要ですよ。
それは否定してませんが。

ただ、
ソース上にSQLを直書して、
StringBuffer#appned
なんて、まじありえない。氏んでよし。


198 :デフォルトの名無しさん:2006/10/08(日) 10:51:38
>>197みたいなレスみると
お前が氏ねよ。って思います。

199 :デフォルトの名無しさん:2006/10/08(日) 10:58:39
>>197
こんな感じ?(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();
   }
}


200 :デフォルトの名無しさん:2006/10/08(日) 11:12:08
SQLを使っても「ソース上に直書して、StringBuffer#appned」なんてまじありえないのだが。
普通はResourceBundleやPreparedStatementを組み合わせるからな。
「SQLを使う」イコール「直書&StringBuffer」なんて発想の奴はHQLも直書するんだろうねw

>>199 それはいくらなんでもダメだよ。

201 :188:2006/10/08(日) 11:29:54
>>200
あなたの言うことは正しい。
SQLを外だしにして、管理しているならまだましだ。
だが、現実はコンサルと称して、そんなことすら
できない無能な奴がいる。
理由は
「複雑なSQLが多いので、ハードコーディングじゃないと
やりにくい」
などと言っていたよ。

そういうやつらはまじ氏んでいいよ。

ただ、ResoureBundleを組み合わせるといっているが、
ようするにそういう場合、ある種のフレームワークを
作っているんだと思うが、そういうフレームワークでは
Hibernateが最強なんだよ。
かけられている工数、開発者のレベルが世界トップクラスだし。

202 :デフォルトの名無しさん:2006/10/08(日) 11:35:50
>>200
>>>199 それはいくらなんでもダメだよ。
なんで?

203 :デフォルトの名無しさん:2006/10/08(日) 12:09:51
>>202
とりあえず、単発のSQLなら判らないことは無いがPreparedStatementを使うほうがベターかな?
あと、サニタライズやなんかをどうするって話も出てくる
SQLインジェクションって言われる脆弱性のほとんどは>>197みたいなソースを使ってることが原因

204 :デフォルトの名無しさん:2006/10/08(日) 12:51:14
>>197
「いまどきJavaの世界にSQL持ち込んでる糞は氏んでよし」って言ってるじゃん
HQLだってSQLのテーブル定義をクラスに置き換えて、結合条件を省略したり継承戦略追加してるだけだし
ソース上に書くかNamedQueryで外出しするかはHibernate使っても選択肢の一つでしかない
>>199のような書き方は、JDBC使ってても普通やらないしw

205 :デフォルトの名無しさん:2006/10/08(日) 13:17:29
今からHibernateのAPIを覚える必要性はないな。
JPAでいいだろ。
コンテナにJBossやjboss-EJB-3.0_Embeddableを使った場合に
JPA実装としてHibernateを内部的に使うことはあるかもしれないが。


206 :デフォルトの名無しさん:2006/10/08(日) 13:33:03
>>203
それは、jdbc を使う(と決めた)場合の技法の問題であって、
後からいくらでも(DAO内部の問題として他に影響を与えずに)
修正の利く問題じゃないの。


207 :デフォルトの名無しさん:2006/10/08(日) 13:42:20
>>206
話がずれてないか?

208 :デフォルトの名無しさん:2006/10/08(日) 14:07:05
>>207
だからさ、SQL直に書かずに済むなら、
そのほうがいい、ってことは誰も否定してないだろう。

自分が言っているのは、じゃあ、SQL直書きが、
「それほど(SQLのコードがわずかでも存在したら、そのシステムが全否定されるほど)深刻な問題なのか?」ということ。



209 :デフォルトの名無しさん:2006/10/08(日) 17:29:54
>>108
パラメータをPreparedStatementで代入することと、SQL直書きが混同されて話されてるからな
前者はJDBCでやるときも同じだから、別にHibernateを選ぶ理由にはならない
後者は別に目くじら立てて否定するようなことでもない。
動的にクエリを組み立てるときはソースに書いたりすることもある。
Criteria使うこともあるだろうけど、JPAでサポートされてないからな

210 :デフォルトの名無しさん:2006/10/08(日) 19:25:28
で、Hibernateってどこまで出来るの?
joinしまくったSQLの生成とかできるの?
これができるのなら導入もありなんだが

211 :デフォルトの名無しさん:2006/10/08(日) 19:30:11
joinぐらいならできるよ。マニュアル見れ。

212 :デフォルトの名無しさん:2006/10/08(日) 23:59:48
>>210
JOIN程度ならHibernate使ったほうが楽
SELECT句やWHERE句ならサブクエリも書ける

213 :デフォルトの名無しさん:2006/10/09(月) 10:17:13
>>205
JPAの実装ってどこにあるの?

214 :デフォルトの名無しさん:2006/10/09(月) 10:55:28
>>213
Hibernate EntityManager

215 :デフォルトの名無しさん:2006/10/09(月) 12:07:17
>>213
つ JBoss EJB3(JPA部分の実装はHibernate)
つ Glassfish/JavaEE SDK(JPA部分の実装はToplink)


216 :デフォルトの名無しさん:2006/10/09(月) 13:12:13
>>196
ん?db4oの話だよね?

リファクターは既存のクラスをさわらないで、新しいクラスを作りそこで行う
既存のクラス>新しいクラスへの変換methodを適当につくる。
既存のクラスを全部ロード>新しいクラスに変換、全部保存
これで既存データもリファクター完了。

既存sqlからのデータ抽出はhibernate使ってれば上記プロセスでOK
jdbcだったら ちょっとつらいかな。

217 :デフォルトの名無しさん:2006/10/09(月) 14:19:15
ibatisとかのこと忘れないであげてください。
っていうかSQL直書きに拘るならよさげなんですが。

218 :デフォルトの名無しさん:2006/10/25(水) 18:27:25
       ,、‐ " ̄:::゙:丶、
    ,r::::l3゙::::::::/ハヽ:ヽ::::、:ヽ
    {::://:::::::// ヽ\ト、:::::::!
    ヾ l:::::::/ 丶   `ヾ ィ、:::|
     |;:r::|  O`  'O ゙ハ|  ORマッピング!?  
      ヽハ :.:.    :.: レ
        ´\ r‐--‐、,ノ    いらんいらん
 r、     r、/ヾ ̄下ヘ
 ヽヾ 三 |:l1、_ヽ/__ .ィヽ
  \>ヽ/ |` }    n_n| |
   ヘ lノ `'ソ     l゚ω゚| |
    /´  /      ̄|. |
    \. ィ   ___ |  |
        | ノ     l |  |

219 :ななすぃ:2006/11/07(火) 22:37:39
特定の言語に依存した環境なんぞクソ。RDBはデータ構造とアルゴリズムを分離す
るためのインフラなんだよ。SQLで書けないシステムなんかつぶし効かんからあと
あと苦労するよ。わかってないやつが集計処理をループで書いたりすんだよな。

220 :デフォルトの名無しさん:2006/11/07(火) 23:21:34
RDBじゃなくってXMLとかでも分離できるんでないの?
RDBMSって長期保存のデータストレージとしては最低最悪の場所だから。

221 :デフォルトの名無しさん:2006/11/08(水) 13:25:26
Execlで保存の方が最低最悪だろ

222 :デフォルトの名無しさん:2006/11/08(水) 15:59:08
んーとRDMSっていうのはデータ量が巨大化してある一線を超えると
CPUの負荷が爆発的に上がってシステムダウンしたりするの。

ある程度、容量に限度があるってことと、
OSの更新の時のデータの移行とかの問題もある。

だから、分離だけが目的ならDBを使うべきじゃない。

223 :デフォルトの名無しさん:2006/11/08(水) 22:16:37
データ量が巨大化しても越えるべき一線かやってこない素敵なストレージを教えてくれよハニー。

224 :デフォルトの名無しさん:2006/11/08(水) 23:06:29
四次元ポケットとか

225 :デフォルトの名無しさん:2006/11/08(水) 23:12:40
ブラックホールとか

226 :デフォルトの名無しさん:2006/11/08(水) 23:27:18
ハクション大魔王の胃袋とか

227 :デフォルトの名無しさん:2006/11/09(木) 00:03:34
/dev/null

228 :デフォルトの名無しさん:2006/11/09(木) 01:28:55
メーカーの工作員は
インターフェースの統合とトランザクションの管理を解きつつ、
RDMSの導入しかないって決め付ける。

ロジックは正しいけど解答は一つではないんだよね。

229 :デフォルトの名無しさん:2006/11/09(木) 09:59:54
>>227
それだ

230 :デフォルトの名無しさん:2006/11/09(木) 10:33:17
でも、実際DBMS使ったほうが楽だぜ
見渡せる範囲ならスケーラビリティあるしでDBMS使って楽すりゃ良いだけじゃね
一線越えたときはうちの会社じゃおさらばした方が良いしな

231 :デフォルトの名無しさん:2006/11/12(日) 11:13:29
>>222
漏れAS/400(中身RS/6000の)を使っているけどDBの容量が増えたからって
CPUの不可が爆発的に上がるなんて事ないんだが・・・。

そりゃ、システム全体のDiskの容量が90%くらいになると
ちょっと遅くなったなぁ、とは感じるけど。

それってWindowsでAccessとかSQL Serverとかの話じゃねーの。

232 :デフォルトの名無しさん:2006/11/12(日) 13:17:45
インデックス張り損ねて全レコードなめまわすようなバカクエリーや
ブロック分断されまくったまま放置してたとかそんなんでしょ。

233 :デフォルトの名無しさん:2006/11/12(日) 13:36:27
>>231
Disk I/OがボトルネックになってCPUのSYSが跳ね上がったことはあるよ。
当時DBのサイズは100GB弱程度でPostgreSQL8.1利用。
OracleならDiskの使い方がもっと上手いんだろうけど。

234 :231:2006/11/12(日) 17:47:37
>>233
それOracleとかPostgreがどーこーじゃなくて、最初のハードウェアと
OSの選定が間違っていたってオチかと。

AIXなりOS/400だと「ある一線」とかは体感しないんだが。
もしかしてWindowsとかLinux使っておいてトロくなるとか
言っているなら、それを基準に「RDBMSとは・・・」と語るのも
微妙なんだが。

235 :デフォルトの名無しさん:2006/11/12(日) 20:01:22
ストレージの劣化の問題もあるし、
ハードウェアのリプレースの時、文字コードの問題もあるだろ。
営業のRDBMSマンセーは異常だと思う。

236 :デフォルトの名無しさん:2006/11/12(日) 21:07:15
それはRDB関係なくおきる問題では・・・。

237 :デフォルトの名無しさん:2006/11/12(日) 21:33:57
規格どおりのXMLだと起きない問題。

238 :デフォルトの名無しさん:2006/12/21(木) 00:05:59
HIbernateは複雑なSQLでもおk
他のもきっとおk

239 :デフォルトの名無しさん:2006/12/23(土) 01:56:38
AS/400ってファイルが排他ロックされるからゴミだよな。
オラクルなら同時更新も可能ですよ。

240 :デフォルトの名無しさん:2006/12/23(土) 10:32:23
>>239
スレ違いだと思うがAS/400は更新モードでロックしたら排他ロックするは当たり前だが。
Oracleは更新モードでロックして他人からも更新できたらそれこそ異常だと思うが。

ゴミアプリしか作れないロック恐怖症の初心者ゴミプログラマには
その方がいいかもしれんな。

241 :デフォルトの名無しさん:2006/12/23(土) 10:34:50
行レベルロックってことじゃね

242 :デフォルトの名無しさん:2006/12/23(土) 11:52:24
ロックしているオブジェクトを他のトランザクションから更新する事はオラクルでも出来まい

243 :デフォルトの名無しさん:2006/12/23(土) 15:48:52
239は分離レベルとかの存在を知らんだけじゃねーのか?

インデックスのないカラムに対して更新モードで全件検索する
SQL投げておいて「ファイルがロックする」とかヌカしていると思うんだが。

244 :デフォルトの名無しさん:2006/12/25(月) 11:23:02
とりあえず239がAS/400もOracleも理解できてないのはわかった。

245 :デフォルトの名無しさん:2006/12/25(月) 19:38:05
まあ、AS/400使いにはCOBOLerの仲間みたいな化石なSEが
ゴロゴロしてるからなぁ、アフォな設定のAS/400でもちょっとイジって
挫折したクチじゃね。

だからと言ってOracleマンセーもどーかと思うが。

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

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

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)