COBOL vs Java 2戦目 151-200

2009年02月24日

1 ：デフォルトの名無しさん：2006/09/13(水) 22:37:48

前スレです。

ttp://pc8.2ch.net/test/read.cgi/tech/1068819212/

151 ：デフォルトの名無しさん：2008/07/24(木) 21:46:12

ローカル変数を使う方法も無いではない。
（プログラム自身を入れ子にする）
しかし普及していない。

俺は以前、A4用紙両面刷りで厚さ1cmぐらいの大きいCOBOLの
リストを見たが、真に驚くべきは、1cmのうち7mmぐらいは、
DATA DIVISION、すなわち（グローバル）変数の定義で占められていたことだ！

152 ：デフォルトの名無しさん：2008/07/25(金) 22:42:55

純粋にCOBOL、JAVAを比較して（レガシーアプリなし、新規構築という条件）
COBOLが優れている点ってないのかな。実行速度が速いとか。
今のとこ”vs”って内容になってない気がする。

153 ：デフォルトの名無しさん：2008/07/26(土) 00:12:17

コボルが殿様でJavaは家来

154 ：デフォルトの名無しさん：2008/07/26(土) 10:47:49

>>152
俺が昔やってたCOBOLの業後バッチ処理だと、
DBの内容を全て固定長のシーケンシャルファイルに吐き出して、
入出力すべてシーケンシャルファイルのバッチプログラムを
数十段も連ねて、一番最後にDBにロードして、、、ということやっていた。

今ではJavaで、殆どSQLでDBをいじっちゃうけど、
処理速度で悩まされることが多い。
SQLをチューニングして何とかなる場合は、それでいいんだが、
DBMSの諸々の設定（あるいはバグ）の問題が絡んでくると厄介。

昔は良かったなぁ、と思うことがよくある。
別にJavaだって、シーケンシャルファイル多段処理方式を
作れば出来るだろうが、やっぱり実行速度が遅いし、
固定長レコードのシーケンシャルファイルを扱うプログラムは、
圧倒的にCOBOLが作りやすい。

155 ：デフォルトの名無しさん：2008/07/26(土) 12:50:22

>別にJavaだって、シーケンシャルファイル多段処理方式を
>作れば出来るだろうが、やっぱり実行速度が遅いし、

iSeriesにはそういうクラスがIBMから提供されているワケだが。
まあ、iSeriesの場合、COBOLよりもRPGの方がもっと高速なので、
COBOLが一番使いにくい言語となっているが。
#最速を言い出すとCになるのでアレだが。

そういうのはJavaが早い遅いではなく、「根本的な使い方や設計が間違っている」
だけかと。

SQLを使ったデータベース操作は「少ないリソースで効率的に運用する」のが
主眼にあるのに対してCOBOLとかで固定長レコードを扱う仕組みは
「横長ＤＢ設計、全レコード総なめ、全更新」と言う大味で無駄なリソース使いまくり
の設計思想なんだから、後者の設計思想でJava+SQLは相性悪いだろ。

156 ：デフォルトの名無しさん：2008/07/27(日) 15:18:08

Java＋SQLが悪いんじゃなくって、コボラが設計したテーブル構造が悪いケースが多いな。
いや、設計と言うのは言いすぎか。レガシーのファイル構造をコピーしているだけなんだから。

157 ：154：2008/07/27(日) 17:50:20

なんか　>>155 も >>156　も、
「>>154 が現在関わっているシステムは、昔の愚鈍な化石のようなコボラーが設計した、
しょうもない物で、それをもってJavaの非効率を言うことはできない」
という前提があるんだが、それは違うんだ。
　
例えばテーブルの設計で言うと、俺が今保守しているJava+SQLのシステムは、
正規化をやり過ぎて、何をするにしても、
テーブルを10個ぐらい join しないとまともな仕事ができない。
それで平気でjoin しまくった複雑なSQLが、処理速度を落としている。

主観的には、昔のCOBOLの多段バッチAPなら
5本を組み合わせて行うボリュームの処理を、
たった１つのSQL、１つのAPで行おうとしている感じ。

まぁテーブルの設計の問題もいろいろあるのだろうが、
昔のCOBOLシステムも、今考えれば結構良かったかもしれないなぁ、
という感想を持っている。

あるいは、考え方だけ昔のCOBOL多段方式を応用してもいいかもしれない。
すなわち、今のJava+SQL（長複雑）　APを、３つ位に分割して、
Java+SQL（簡単） + Java+SQL（簡単） + Java+SQL（簡単）
と作り直して実験してみたいなぁ、といつも思っているんだが、
日々の仕事で、そんな余裕はない。

159 ：デフォルトの名無しさん：2008/07/29(火) 12:38:11

そうかな。凝るとろくなことないじゃん。

160 ：デフォルトの名無しさん：2008/07/29(火) 12:49:57

単純な処理の組み合わせで作った方が、
障害が起こったとき対処がラクだと思うよ。

PR

161 ：154：2008/07/29(火) 23:04:31

>>158
>それにテーブル10個JOINしないと、の件もフカシが入っていると思うが。

フカシじゃない。遅いSQLを解析するときに、1行あたり単純な論理式一個
（and や or で改行する）に崩すんだが、それで500行になったりする。

>本気だとしたら、それこそコボラーかAccessヲタが設計したんだろう。

「どうせコボラーが作った正規化もクソもない横長テーブルなんだろ」
と言われて、いやそうじゃない、正規化しすぎて細切れになってしまったんだ、
と返答すると、それこそコボラーが設計したんだろうですかそうですか。

>悪いんだが、処理速度の改善策としてこんな悪手を選択するエンジニアが
>「COBOLの方式もよい」なんて発言するって事はRDBMSの基礎も
>解っていない素人にしか思えん。

確かに俺はSQLについてネットでシコシコ調べて市販の参考書買ってきて読んで、
という素人レベルだが、では、この場合の処理速度向上策はどうすべきか？
保守フェーズで、予算もシケている状況なんで、
「テーブル構造の見直し」
なんて夢みたいな話は抜きで。
冗談抜きで>>158に聴きたい。

162 ：デフォルトの名無しさん：2008/07/30(水) 00:23:55

自分が素人と思っているなら金払ってSIerに相談すれば？
漏れも遅いとか言いながらJava+SQLを選択する理由が解らんが。

163 ：デフォルトの名無しさん：2008/07/30(水) 02:39:46

>>161
リアルタイムでの参照は必要？
必要なければ、定期的に参照用テーブルにコピーするという手もある。

10テーブルをjoinしたぐらいでそんなに遅くなるってことは、インデックスが
きちんと設定されてないのかもね。インデックスの追加も無理？

164 ：154：2008/07/30(水) 07:47:12

出勤前にかきこ

>>162
>自分が素人と思っているなら金払ってSIerに相談すれば？

普段仕事出している外注に相談もしていろいろやってるよ。でも効果なし。

>漏れも遅いとか言いながらJava+SQLを選択する理由が解らんが。

なんとなくハイカラだったからじゃないの？
俺は開発の後期から入ってそのまま保守やってるからその辺は知らない。

>>161
>リアルタイムでの参照は必要？
必要なものとそうでないものがある。必要でないものについては、
参照用テーブルあるいはビューを使うというのがやっぱりベターか。

>インデックスが
>きちんと設定されてないのかもね。

お察しの通り。実際、デバッグ環境上でインデックスを一部追加して
“劇的に”速くなったケースもある。
でも、対象テーブルは日中オンラインで頻繁に更新されるものなので、
インデックス追加によるテーブル更新時のオーバーヘッドがどの位のものか、
正直よく分からないので、その方式は却下されちゃったよ。
デバッグ環境で実験することは出来ても、本番環境ではアクセス量が
圧倒的に違うからね。本番で試しにやってみる、ということも出来ないし。
結局、そのケースは俺がSQLをチクチク直して、”まぁまぁ”速くして対応した。

いろいろ考えてくれてありがとう。

165 ：デフォルトの名無しさん：2008/07/30(水) 11:22:50

レガシーからJavaへの移行では、やっぱり苦労しているところが多いみたいだね。

俺は、Enterprise Javaのコンサルもやってるから、そういうのの後始末をやらされることも多いよ。
最初からプロジェクトに入れてくれれば、皆幸せになれるのに、痛い目にあわないと分からないからなぁ。

166 ：デフォルトの名無しさん：2008/07/30(水) 18:33:20

そもそもレガシーからJavaへ移行とか考える方がおかしいと思うが。
あんなん、移行とか考えずに「作り直します」の方向性でやらないとやってられないが。

ただこういう時はレガシーな技術者が壮絶に非協力的なんだよなぁ。

167 ：デフォルトの名無しさん：2008/08/01(金) 18:30:04

移行はメインフレームから、ＵＮＩＸ−ＣＯＢＯＬへの移行の仕事が多いらしいですねえ。
ＵＮＩＸの方がメリットあるのかなあ・・・。どうなんでしょうねえ。

168 ：デフォルトの名無しさん：2008/08/01(金) 18:40:35

Solarisね。Ｆさん案件だと多いね。
俺も、汎用機／オフコンのコストに耐えられなくなったユーザがUNIX／Windowsに移行するのを何回か経験したけど、
まんま移行するならともかく、１からのリライトでCOBOL採用ってのは、今の時期かなりチャレンジャーだと思う。
（ちなみにフロントはVB.netとか、パワービルダとか、ビジネスロジックをCobolで書いたWeb。どれもヤバイべｗ）

169 ：デフォルトの名無しさん：2008/08/01(金) 18:44:38

おお、そういう話が聞きたかったのです。
うわー、そいつはトラブル多そうですね・・・。
ヤバイヤバイｗｗ

170 ：デフォルトの名無しさん：2008/08/01(金) 23:01:41

各社ともマイグレ用のミドルウェアを用意しているようだが、
こんなの使わされる客がかわいそうだ

玉石混淆の石だけが残っているってのが、COBOLer最大の問題点だな

PR

171 ：デフォルトの名無しさん：2008/08/06(水) 22:19:47

COBOLerどもうぜー

技術では勝てないから心理戦かよ

172 ：デフォルトの名無しさん：2008/08/07(木) 14:37:04

どのへんがどう心理なんだよｗｗｗ

173 ：デフォルトの名無しさん：2008/08/08(金) 20:56:47

>>164
流れをちゃんと読んでないでカキコさせて貰う。

JOINが十個以上あるなんてのをJava+SQLで
処理する場合、n+1問題をわざと発生させるような
ソースを書いて、その替わりにCacheをアスペクトするような
格好にすると劇的に早くなる場合があるよ。

ま、データ構造と大きさ次第なんだけどね。

174 ：デフォルトの名無しさん：2008/08/08(金) 22:24:20

「場合があるよ」

非常に技術的な回答だ。

175 ：デフォルトの名無しさん：2008/08/09(土) 00:15:11

DB2とかだと小さいテーブルをオンメモリで処理するとかの機能があるから
変にJavaやCOBOLでアレコレするよりもRDBMSの最適化に任せた方が
いい場合もあるな。ｗ

あとしょーもない結合(1:男,2:女とか)するくらいならSQLのCASE文で済ませたほうが
速い場合がある。と言うか当たり前だけど大抵速いな。

177 ：デフォルトの名無しさん：2008/08/14(木) 19:22:35

会社でCOBOL経験者向けにjavaの勉強会の資料を作らなきゃいけないんだけど、
COBOLは静的変数しか無いのか。
メモリーと、オープン系と汎用機のアーキテクチャの話から入る感じが良さそうだな。
それが分かれば基本手続き指向なので言語的には問題無いのかな。

そういえばcobolでテーブル定義があれなのは、テーブル定義というか
データと表示が密接に関連してるからっぽいね。

178 ：デフォルトの名無しさん：2008/08/14(木) 21:30:20

コボラーに普通のプログラムを勉強させようとするのは酷すぎる
そっとしといてやれ

179 ：デフォルトの名無しさん：2008/08/15(金) 01:25:52

>>177
そんなことしたら、バッケンレコードを更新されるぞ。
面倒でも、構造化から教えてあげないと駄目なんじゃないの？

180 ：デフォルトの名無しさん：2008/08/15(金) 08:33:11

どうせコボル風にしか使えないけどな、あいつら

181 ：デフォルトの名無しさん：2008/08/15(金) 10:12:30

×　あいつら
○　おれら

PR

182 ：デフォルトの名無しさん：2008/08/16(土) 08:06:48

COBOLer向けのJavaの講師をしていたことが有るけど、彼らはメソッドが理解
できない。
以前、真顔で「メソッドって2次入り口点なんですね」と言われたことがある。

プログラムが上から順番じゃなくて、呼ばれた順に実行されるというのも理解
できない。

それに、COBOLにあるのは変数じゃなくてレコードだから・・・変数の概念も
Javaとはだいぶ違うし・・・。

まさに>>178の言う通り。

183 ：デフォルトの名無しさん：2008/08/16(土) 09:00:42

>>182
Javaだからとも云えるな。私は完全なコボラーだったけれど、
30才過ぎてからLispとPrologを難なく覚えた。この二つの言語は
COBOLと似たところが全くなく、かつ単純な構文要素しかないから
素直な初心者として学習できた。Javaだったらそうはいかなかった
に違いない。COBOLの知識から意味を理解しようとしてしまう部分が
少なくないのではないか。学習課題もCOBOLよりはるかに多い。

184 ：デフォルトの名無しさん：2008/08/16(土) 13:57:21

オブジェクト指向って、色々なポイントがあるけどさ、
とりあえず抽象データ型として教えるってことはできんのかな？
要するにカプセル化だけ。
抽象データ型は、普通の手続き型言語とも相性がいいと思うんだけど。

185 ：デフォルトの名無しさん：2008/08/16(土) 21:15:41

なるほどLispとか全然違ってるほうが先入観無くて良いのかな。
確かにメモリ関係とか知らないのにオブジェクト指向分からんとか
言ってるのを見ると納得。

186 ：デフォルトの名無しさん：2008/08/17(日) 11:28:39

>>186
http://imepita.jp/20080726/075540

187 ：デフォルトの名無しさん：2008/08/19(火) 18:28:35

そう？
クラスとかメソッドとか、
要するに人様の作ったもんを使わせてもらうだけの話じゃないの？？

まあ、自分で作る場合もあるかもだけどさ。
単純に、文化の違いだよ。

188 ：デフォルトの名無しさん：2008/08/19(火) 22:20:31

多テーブルJOINは遅いがJOIN不要なテーブルまでJOINしてることがある。

・選択条件だけに使ってるテーブル。
　JOINから外して相関サブクエリ(EXISTS)にした方が良い。
　EXISTSは1件見つけたら処理中止するから速い。
・トランザクションレコードに比べて件数が多いマスタとJOINしてる場合。
　マスタの一部のレコードしか参照しないならスカラサブクエリにした方が速い。
　SELECT句が冗長になるが、EXISTSと合わせ技で30分以上かかってた処理を10秒で終わらせた時がある。

189 ：デフォルトの名無しさん：2008/08/20(水) 10:51:42

なんでテーブルの結合とかする必要があるの？？
トランザクションレコードを用意してるってことは、
更新は夜間とかに一気にやるんだよね。それはいいと思うんだけど。

190 ：デフォルトの名無しさん：2008/08/27(水) 10:20:48

結合なんかやるから遅いんじゃないの？？

191 ：デフォルトの名無しさん：2008/08/27(水) 23:25:12

やらなきゃいけないんだからしょうがないでしょ

PR

192 ：デフォルトの名無しさん：2008/08/27(水) 23:35:40

仕事だもんな・・・ｗ

193 ：デフォルトの名無しさん：2008/08/28(木) 01:05:26

テーブルなんざ参照と更新だけでいいだろ。
なんでやらなきゃいけないのかも答えられないのか。

194 ：デフォルトの名無しさん：2008/08/28(木) 01:54:32

>>193
本気なのか釣りなのかわからんが（以下略）。

195 ：デフォルトの名無しさん：2008/08/28(木) 09:52:05

仕様に疑問があっても、
言われた通りに言われた事だけをやるのか。
テーブル別々に参照すればいいじゃないか。
なんで結合なんかしなきゃいかんのだ。
ＤＢなんだろ？ＣＯＢＯＬとかのファイルじゃないんだろ？？
レコード単位でしか見れないわけじゃないんだろ？
見たい、更新したいフィールドだけ、触ればいいのではないか？？
よけいな事しない方が速いだろ？

196 ：デフォルトの名無しさん：2008/08/29(金) 00:36:17

例えば、
在庫テーブル　　　　（品目コード、数量）　と
品目情報テーブル　（品目コード、名称、単価）

があって、在庫の一覧表（品目コード、名称、在庫額）を作りたい場合、
品目コードをキーに２つのテーブルを結合することを考えないか普通は？

197 ：デフォルトの名無しさん：2008/08/29(金) 09:52:57

そうか。なるほど。

その例の場合、
在庫テーブルと、品目情報テーブルを読み込んで、
在庫の一覧表テーブルを、新しく作れば良くない？？
結合とか、余計な機能使ったら、遅くならないの？？
っていうか、在庫の一覧表テーブルを、新しく作っても遅いじゃん。
最初から、在庫の一覧表テーブルは用意しておいて、
在庫額だけ、数量ｘ単価を（プログラムで）計算して、更新すれば良くない？？

198 ：デフォルトの名無しさん：2008/08/29(金) 12:41:41

>>197
在庫テーブルにはいつ追加、削除があるかもわからない。
在庫一覧テーブルを同時更新したとしても、最終的に、
在庫一覧表を表示する以前に一度は、
在庫一覧テーブルと在庫テーブル、品目情報テーブルの
整合性チェックをしなくてはならない。この事から、
在庫一覧表テーブルを用意しておいた方が速いとは必ずしも
言えない。

199 ：デフォルトの名無しさん：2008/08/29(金) 14:29:36

>>197
> 結合とか、余計な機能使ったら、遅くならないの？？

結合はRDBの基本中の基本なんだが。

頼むから、COBOLの世界から出てこないでくれ。
間違っても、DB設計なんて手を出さないでくれ。
こっちも、そちらの世界には手を出さないから。

200 ：デフォルトの名無しさん：2008/08/29(金) 14:31:34

基幹系の仕事はJavaには回ってこないから問題無い。

PR

トラックバック&コメント

まだトラックバック、コメントがありません。

COBOL vs Java 2戦目 101-150 »
« 【初心者】Java質問･相談スレッド124【歓迎】 0-50

タグクラウド

COBOL vs Java 2戦目 151-200 | Javaの話題

COBOL vs Java 2戦目 151-200

タグ

関連するエントリー

トラックバック&コメント