06/05/25 17:54:00
>>949
意味わからん。JARファイルをクラスパスに追加して
ソースコードからDataSourceなどで呼び出すだけで使えるんだが。
952:949
06/05/25 18:19:09
そういうつもりで言ってるんだけど。TYPE-4のJDBCだよね。他にもJNI使うTYPEもあるでしょ。
もしかして、みんなが自分に反対してるとか思い込んでないかい？
953:949
06/05/25 18:20:17
と思ったけど、単に>>951がPure Javaなドライバしか知らないという可能性に思い当たった。
954:仕様書無しさん
06/05/25 18:28:19
>>953
煽るな。そんなことはない。
JDBCの入門書を読むとかならずType1～4までの
説明が出るだろ。
955:949
06/05/25 18:33:21
>>954
煽るつもりはなかったよ。
そもそも直接JDBC触る機会が激減してるし、TYPE-4じゃないドライバなんてめったに使わないし。
だから知らないのかなーと思っただけです。気分を害されたら陳謝。
956:仕様書無しさん
06/05/25 18:45:51
JDBCドライバのタイプも知らんと。はあ。さすがJava厨ﾀﾝだな。
957:仕様書無しさん
06/05/25 19:01:40
わかったのは>>944が果てしなく厨であることだけ。
958:仕様書無しさん
06/05/25 21:09:43
>>956==>>944だよな
959:仕様書無しさん
06/05/25 22:36:16
>>957
>>947モナー
960:仕様書無しさん
06/06/05 07:00:01
Javaでの開発４年目ですが、
OracleでのアクセスではPL-SQLのほうが、
早いように思います。（Oracle上のライブラリーキャッシュに入るため）
JDBC経由では、SQL文の解析や実行の遅さがモロに
出るように思います。
>>JDBCの入門書を読むとかならずType1～4までの
>>説明が出るだろ。
Type2より,Type4の方が遅いでしょ、
マニュアルにも書いてあるし、
Pure Javaは魅力だが。。。。
>>まさにオッサン世代ですね。だからガーベッジコレクタの
>>動作原理も知らない化石的思考といわれる。
ガーベージコレクションもいい加減であるため、
JAVAVMの仕様では、ガーベージコレクションはいつ走るか
わからない、命令もあるが走らせるように努力するっていう感じ
だったと思う。
では、回答頼む。
961:仕様書無しさん
06/06/05 07:21:42
現在、JAVAで作成したバッチJOBをPL-SQLやPro-Cなどで
作成し直したっと言う話を良く聞く、
私も、チューニングで
１）JAVA（8時間実行）→PL-SQL（1時間実行）に
２）JAVAのSQLのチューニング（１時間実行）→10分実行
３）JAVA（５日以上実行）→PL-SQL（＋SQLのチューニング）（１時間実行）
この辺はOracleMasterの
パフォーマンスチューニングにも少しだけ出てきます。
962:仕様書無しさん
06/06/05 07:40:53
>>960 論点がよくわかんない。
ストアドプロシジャの方が速いという話だとしたら -> 当たり前
1. 使えばいいじゃん。
2. 使わないと仮定して、Statementを再利用できる文脈なら再利用
してなかったら文句はPGに。
しても性能向上しなかったら文句はドライバに。
CだったらPro-Cが使えるのにという話だとしたら
まぁそれはそうかも。個人的にはPro-Cあまり好きじゃないけどね。
963:仕様書無しさん
06/06/05 07:41:48
ま、JDBC経由せずに、
MQ（電文）使うんだったら、
JAVAでもいいですけどね。
964:仕様書無しさん
06/06/05 07:45:52
962すいません、
960,961,983書きました、
>>>960 論点がよくわかんない。
>ストアドプロシジャの方が速いという話だとしたら -> 当たり前
だったらいいです、最近なんでもJAVA使って、
デスマにする人多いんで。
965:仕様書無しさん
06/06/05 08:03:11
>>964 そういうことね。
ストアドプロシジャ書かせても、必要性ないのにカーソル使いまくりということもあり得るw
966:仕様書無しさん
06/06/05 08:07:49
>>>964 そういうことね。
>ストアドプロシジャ書かせても、必要性ないのにカーソル使いまくりということもあり得るw
確かに（笑）
967:仕様書無しさん
06/06/06 05:45:42
>>960 論点がよくわかんない。
>ストアドプロシジャの方が速いという話だとしたら -> 当たり前
> 1. 使えばいいじゃん。
> 2. 使わないと仮定して、Statementを再利用できる文脈なら再利用
> してなかったら文句はPGに。
Statementを再利用しても、性能向上なんかは関係ない
Statementを再利用してもそれはガーベージコレクションが
すこし、早くなるかどうかぐらいの問題で、
性能はあまり関係ない、
SQLのチューニングするほうが早くなる。
968:仕様書無しさん
06/06/06 07:37:17
AP鯖がStatementキャッシュ機能提供してたりしない？
969:仕様書無しさん
06/06/06 07:50:30
>AP鯖がStatementキャッシュ機能提供してたりしない？
でも、焼け石に水だと思う。
970:仕様書無しさん
06/06/06 07:56:57
> SQLのチューニングするほうが早くなる。
しかもRDBMS 固有の機能を使うと劇的に速くなる可能性がある。
Oracle 9i 以降の CONNECT BY 句なんか、うまくハマるとすごい。
ただ、SQL で再帰を書く香具師はあまりおらんので、どう使ったら
いいか悩むだろうが。
971:仕様書無しさん
06/06/06 09:58:44
>>969
理念的には、パース工程が省かれる(ことがある)ので、意味はあると思う。
972:仕様書無しさん
06/06/06 15:41:25
もはやJava自体の速さは関係なくなってるね
973:仕様書無しさん
06/06/06 19:50:47
>>>969
>理念的には、パース工程が省かれる(ことがある)ので、意味はあると思う。
10時間のバッチJOBを９時間５０分にしても、
ENDユーザは喜ばないが、
>もはやJava自体の速さは関係なくなってるね
関係あります。
Javaは遅いので、
最近バッチJOBでJavaを使うのは、
あまり見ない。
アーキテクチャーを
思い出せば遅いのはあたりまえ。
974:仕様書無しさん
06/06/06 20:36:01
>>972
しーっ！せっかく話を逸らせたのに！
975:仕様書無しさん
06/06/06 23:23:39
ところでSwingってネットワークが重いと動作も重くならない？
接続してねぇときでも。
ネットが重いときにsetVisible(true)ってやってもいつまでたっても画面が表示されねぇ。
976:仕様書無しさん
06/06/06 23:25:56
案件情報で
JAVA、ストラッツ、PL-SQLまたはPro-C経験者
なんかあったら、
大体、
画面系：ストラッツ、JAVA
バッチ系：PL-SQLまたはPro-C
になっている。
案件情報で
JAVA、ストラッツ、DB2、COBOL経験者
だったら、
JAVA、ストラッツ、
MQ（電文）、汎用機側でDB2、COBOL
なんかになっている。
基本的に、
Statementの再利用と性能向上はあまり関係ないと思う。
コードが減ってガーベージコレクションのタイミングが
変わるぐらい、それよりもJDBC経由だったら、
①重たいSQLを投げない
②FROM句,WHERE句の記述方法に気をつける。
③SQLは実行計画などを見て最適なものにする。
（INDEXやHINT文などを使用する。）
977:仕様書無しさん
06/06/07 00:36:54
速度面で言えばシェルとかPro-Cなんかと比べてJavaのバッチは結構有利なはずでは。
メモリとかそっちのほうがネックなんじゃね？
978:仕様書無しさん
06/06/07 00:41:40
>>977さんへ
まじめに言ってる？
979:仕様書無しさん
06/06/07 01:02:21
>>978
別に深く考えたわけじゃないけど。
何がネックになるかな？
980:仕様書無しさん
06/06/07 01:20:40
>>977
> ～なはず
妄想乙
981:仕様書無しさん
06/06/07 01:38:39
最近PL-SQLやPro-Cが見直されてきたのは、
JAVAでバッチJOBを作成して、
夜間バッチが夜間に終わらなかったなどの、
不具合が多くの企業であり、PL-SQLやPro-Cで
作成し直した経緯があるため。
そのため、以前みたいにあまりJAVAJAVA言わなくなった。
982:仕様書無しさん
06/06/07 01:54:34
毎回プロセス上げてやらなきゃいかんようなことにJavaを使ったら
HotSpotもなんも効きやしないからな。
# とV2Cからパピコ
983:仕様書無しさん
06/06/07 02:24:46
V2C作った人はすごいと思う
でもJavaの表現力の限界はV2C止まりだと思う
984:仕様書無しさん
06/06/07 04:22:24
確かに。よくがんばったなーと思う。
でも、がんばらなくても同じことができる環境の方がよっぽど優れていると思う。
985:仕様書無しさん
06/06/07 08:08:57
どうでもいいが
・PL/SQL
・Pro*C
さらに言えば、Pro*C で書けば劇的に速度が上がるわけではない。
アプリケーションが直接 Oracle Net と会話できるために
若干オーバーヘッドが減る程度。
986:仕様書無しさん
06/06/07 12:35:22
>どうでもいいが
> ・PL/SQL
> ・Pro*C
>さらに言えば、Pro*C で書けば劇的に速度が上がるわけではない。
>アプリケーションが直接 Oracle Net と会話できるために
>若干オーバーヘッドが減る程度。
自ら敗北を認めたようですね、
Oracle Net と会話できるためっと記述しているが、
だから早いのである。
JAVAが遅いのはJDBCっと何回も書いた、
JDBCを経由しないので早いのである。
987:仕様書無しさん
06/06/07 12:40:23
勝負してたのか、わからなかった。
誰と勝ち負け争ってんだ？
988:985
06/06/07 13:08:23
>>987
986の脳内じゃね？知らんけど。
しかも
>JAVAが遅いのはJDBCっと何回も書いた、
まるで理解できてない/する気がないようだ。
989:仕様書無しさん
06/06/07 18:04:10
基本的にここに書き込んでいる人
私の想像ですが。
C,C++支持者：
スキル:C,C++,JAVAを実務で経験した人。
推定年齢:3?～4?
C,C++,JAVAを経験して、その上でC,C++を支持している。
他の言語も実務経験あり。
JAVA支持者：
スキル:JAVAのみ実務で経験した人。
推定年齢:25～29
EXCELマクロやVBAすら知らない。
基本的に他の言語は本で読んだ程度。
990:仕様書無しさん
06/06/07 18:04:47
基本的にこの掲示板で、
書き込んでいる人に仕事を頼むとする？
CSVファイルをDBに落とす。（緊急）
13:00ぐらいに言うとする。
C,C++支持者：
はSQL*LoaderをDIRECT INSERTで使用し、
ドキュメント作成も完了し、
定時退社する。
JAVA支持者：
一件、一件ファイルを読みINSERTするプログラムをJAVAで組む
残業、徹夜する。
ドキュメント作成も入れると
最低でも、２、３日はかかりそう。
991:仕様書無しさん
06/06/07 18:35:45
なんで長々と書くかな。JAVA厨は低スキルって言いたいだけで、それなら同意してやるのに。
面白いとでも思ったの？頭悪そうだから板から出てって。
992:仕様書無しさん
06/06/07 18:49:34
>>989
お前はただたんにJavaが嫌いというだけで
思考停止に陥って想像力がずいぶんと低下しているようだ。
993:仕様書無しさん
06/06/07 18:50:40
>>990
たまたまお前の周りにいるJava支持者が
その程度に人間であってその程度の人間にしか
出会えなかったことをうらむんだな
994:仕様書無しさん
06/06/07 19:46:44
>>993
日本語でおｋ
995:仕様書無しさん
06/06/07 20:01:07
jajakartaのコミッターの人でさえ、
バッチJOBの設計には、
PL/SQLを使うのを知っていていってますか？
996:仕様書無しさん
06/06/07 22:01:46
世の中にはOracleしか存在しないのか?
997:仕様書無しさん
06/06/07 22:13:49
Javaからストアド呼べばいいじゃん。
998:仕様書無しさん
06/06/07 23:18:46
>>996
質問に答えろ
999:仕様書無しさん
06/06/08 00:00:24
どれに？
1000:仕様書無しさん
06/06/08 00:22:39
1000
1001:１００１
Over 1000 Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。