COBOL vs Java 2戦目
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
2006/09/13(水) 22:37:48ttp://pc8.2ch.net/test/read.cgi/tech/1068819212/
0153デフォルトの名無しさん
2008/07/26(土) 00:12:170154デフォルトの名無しさん
2008/07/26(土) 10:47:49俺が昔やってたCOBOLの業後バッチ処理だと、
DBの内容を全て固定長のシーケンシャルファイルに吐き出して、
入出力すべてシーケンシャルファイルのバッチプログラムを
数十段も連ねて、一番最後にDBにロードして、、、ということやっていた。
今ではJavaで、殆どSQLでDBをいじっちゃうけど、
処理速度で悩まされることが多い。
SQLをチューニングして何とかなる場合は、それでいいんだが、
DBMSの諸々の設定（あるいはバグ）の問題が絡んでくると厄介。
昔は良かったなぁ、と思うことがよくある。
別にJavaだって、シーケンシャルファイル多段処理方式を
作れば出来るだろうが、やっぱり実行速度が遅いし、
固定長レコードのシーケンシャルファイルを扱うプログラムは、
圧倒的にCOBOLが作りやすい。
0155デフォルトの名無しさん
2008/07/26(土) 12:50:22>作れば出来るだろうが、やっぱり実行速度が遅いし、
iSeriesにはそういうクラスがIBMから提供されているワケだが。
まあ、iSeriesの場合、COBOLよりもRPGの方がもっと高速なので、
COBOLが一番使いにくい言語となっているが。
#最速を言い出すとCになるのでアレだが。
そういうのはJavaが早い遅いではなく、「根本的な使い方や設計が間違っている」
だけかと。
SQLを使ったデータベース操作は「少ないリソースで効率的に運用する」のが
主眼にあるのに対してCOBOLとかで固定長レコードを扱う仕組みは
「横長ＤＢ設計、全レコード総なめ、全更新」と言う大味で無駄なリソース使いまくり
の設計思想なんだから、後者の設計思想でJava+SQLは相性悪いだろ。
0156デフォルトの名無しさん
2008/07/27(日) 15:18:08いや、設計と言うのは言いすぎか。レガシーのファイル構造をコピーしているだけなんだから。
0157154
2008/07/27(日) 17:50:20「>>154 が現在関わっているシステムは、昔の愚鈍な化石のようなコボラーが設計した、
しょうもない物で、それをもってJavaの非効率を言うことはできない」
という前提があるんだが、それは違うんだ。
例えばテーブルの設計で言うと、俺が今保守しているJava+SQLのシステムは、
正規化をやり過ぎて、何をするにしても、
テーブルを10個ぐらい join しないとまともな仕事ができない。
それで平気でjoin しまくった複雑なSQLが、処理速度を落としている。
主観的には、昔のCOBOLの多段バッチAPなら
5本を組み合わせて行うボリュームの処理を、
たった１つのSQL、１つのAPで行おうとしている感じ。
まぁテーブルの設計の問題もいろいろあるのだろうが、
昔のCOBOLシステムも、今考えれば結構良かったかもしれないなぁ、
という感想を持っている。
あるいは、考え方だけ昔のCOBOL多段方式を応用してもいいかもしれない。
すなわち、今のJava+SQL（長複雑） APを、３つ位に分割して、
Java+SQL（簡単） + Java+SQL（簡単） + Java+SQL（簡単）
と作り直して実験してみたいなぁ、といつも思っているんだが、
日々の仕事で、そんな余裕はない。
0158デフォルトの名無しさん
2008/07/27(日) 19:13:59>正規化をやり過ぎて、何をするにしても、
>テーブルを10個ぐらい join しないとまともな仕事ができない。
>それで平気でjoin しまくった複雑なSQLが、処理速度を落としている。
>主観的には、昔のCOBOLの多段バッチAPなら
>5本を組み合わせて行うボリュームの処理を、
>たった１つのSQL、１つのAPで行おうとしている感じ。
漏れ、ABAA〜ABB9みたいなテーブル数１０個以上で正規化もクソもない多段バッチ
のCOBOLのプログラム見たことあるけど。
こういう糞設計もCOBOLerが独壇場に感じる。
それにテーブル10個JOINしないと、の件もフカシが入っていると思うが。
本気だとしたら、それこそコボラーかAccessヲタが設計したんだろう。
ちなみに昔の人でもいい設計する人はいる。だからCOBOLと言う言語自体は全否定はしないが
実際に許せるレベルの設計できる人は万分の一程度だろうなぁ。
＞Java+SQL（簡単） + Java+SQL（簡単） + Java+SQL（簡単）
悪いんだが、処理速度の改善策としてこんな悪手を選択するエンジニアが
「COBOLの方式もよい」なんて発言するって事はRDBMSの基礎も
解っていない素人にしか思えん。
0159デフォルトの名無しさん
2008/07/29(火) 12:38:110160デフォルトの名無しさん
2008/07/29(火) 12:49:57障害が起こったとき対処がラクだと思うよ。
0161154
2008/07/29(火) 23:04:31>それにテーブル10個JOINしないと、の件もフカシが入っていると思うが。
フカシじゃない。遅いSQLを解析するときに、1行あたり単純な論理式一個
（and や or で改行する）に崩すんだが、それで500行になったりする。
>本気だとしたら、それこそコボラーかAccessヲタが設計したんだろう。
「どうせコボラーが作った正規化もクソもない横長テーブルなんだろ」
と言われて、いやそうじゃない、正規化しすぎて細切れになってしまったんだ、
と返答すると、それこそコボラーが設計したんだろうですかそうですか。
>悪いんだが、処理速度の改善策としてこんな悪手を選択するエンジニアが
>「COBOLの方式もよい」なんて発言するって事はRDBMSの基礎も
>解っていない素人にしか思えん。
確かに俺はSQLについてネットでシコシコ調べて市販の参考書買ってきて読んで、
という素人レベルだが、では、この場合の処理速度向上策はどうすべきか？
保守フェーズで、予算もシケている状況なんで、
「テーブル構造の見直し」
なんて夢みたいな話は抜きで。
冗談抜きで>>158に聴きたい。
0162デフォルトの名無しさん
2008/07/30(水) 00:23:55漏れも遅いとか言いながらJava+SQLを選択する理由が解らんが。
0163デフォルトの名無しさん
2008/07/30(水) 02:39:46リアルタイムでの参照は必要？
必要なければ、定期的に参照用テーブルにコピーするという手もある。
10テーブルをjoinしたぐらいでそんなに遅くなるってことは、インデックスが
きちんと設定されてないのかもね。インデックスの追加も無理？
0164154
2008/07/30(水) 07:47:12>>162
>自分が素人と思っているなら金払ってSIerに相談すれば？
普段仕事出している外注に相談もしていろいろやってるよ。でも効果なし。
>漏れも遅いとか言いながらJava+SQLを選択する理由が解らんが。
なんとなくハイカラだったからじゃないの？
俺は開発の後期から入ってそのまま保守やってるからその辺は知らない。
>>161
>リアルタイムでの参照は必要？
必要なものとそうでないものがある。必要でないものについては、
参照用テーブルあるいはビューを使うというのがやっぱりベターか。
>インデックスが
>きちんと設定されてないのかもね。
お察しの通り。実際、デバッグ環境上でインデックスを一部追加して
"劇的に"速くなったケースもある。
でも、対象テーブルは日中オンラインで頻繁に更新されるものなので、
インデックス追加によるテーブル更新時のオーバーヘッドがどの位のものか、
正直よく分からないので、その方式は却下されちゃったよ。
デバッグ環境で実験することは出来ても、本番環境ではアクセス量が
圧倒的に違うからね。本番で試しにやってみる、ということも出来ないし。
結局、そのケースは俺がSQLをチクチク直して、"まぁまぁ"速くして対応した。
いろいろ考えてくれてありがとう。
0165デフォルトの名無しさん
2008/07/30(水) 11:22:50俺は、Enterprise Javaのコンサルもやってるから、そういうのの後始末をやらされることも多いよ。
最初からプロジェクトに入れてくれれば、皆幸せになれるのに、痛い目にあわないと分からないからなぁ。
0166デフォルトの名無しさん
2008/07/30(水) 18:33:20あんなん、移行とか考えずに「作り直します」の方向性でやらないとやってられないが。
ただこういう時はレガシーな技術者が壮絶に非協力的なんだよなぁ。
0167デフォルトの名無しさん
2008/08/01(金) 18:30:04ＵＮＩＸの方がメリットあるのかなあ・・・。どうなんでしょうねえ。
0168デフォルトの名無しさん
2008/08/01(金) 18:40:35俺も、汎用機／オフコンのコストに耐えられなくなったユーザがUNIX／Windowsに移行するのを何回か経験したけど、
まんま移行するならともかく、１からのリライトでCOBOL採用ってのは、今の時期かなりチャレンジャーだと思う。
（ちなみにフロントはVB.netとか、パワービルダとか、ビジネスロジックをCobolで書いたWeb。どれもヤバイべｗ）
0169デフォルトの名無しさん
2008/08/01(金) 18:44:38うわー、そいつはトラブル多そうですね・・・。
ヤバイヤバイｗｗ
0170デフォルトの名無しさん
2008/08/01(金) 23:01:41こんなの使わされる客がかわいそうだ
玉石混淆の石だけが残っているってのが、COBOLer最大の問題点だな
0171デフォルトの名無しさん
2008/08/06(水) 22:19:47技術では勝てないから心理戦かよ
0172デフォルトの名無しさん
2008/08/07(木) 14:37:040173デフォルトの名無しさん
2008/08/08(金) 20:56:47流れをちゃんと読んでないでカキコさせて貰う。
JOINが十個以上あるなんてのをJava+SQLで
処理する場合、n+1問題をわざと発生させるような
ソースを書いて、その替わりにCacheをアスペクトするような
格好にすると劇的に早くなる場合があるよ。
ま、データ構造と大きさ次第なんだけどね。
0174デフォルトの名無しさん
2008/08/08(金) 22:24:20非常に技術的な回答だ。
0175デフォルトの名無しさん
2008/08/09(土) 00:15:11変にJavaやCOBOLでアレコレするよりもRDBMSの最適化に任せた方が
いい場合もあるな。ｗ
あとしょーもない結合(1:男,2:女とか)するくらいならSQLのCASE文で済ませたほうが
速い場合がある。と言うか当たり前だけど大抵速いな。
0176デフォルトの名無しさん
2008/08/09(土) 08:56:510177デフォルトの名無しさん
2008/08/14(木) 19:22:35COBOLは静的変数しか無いのか。
メモリーと、オープン系と汎用機のアーキテクチャの話から入る感じが良さそうだな。
それが分かれば基本手続き指向なので言語的には問題無いのかな。
そういえばcobolでテーブル定義があれなのは、テーブル定義というか
データと表示が密接に関連してるからっぽいね。
0178デフォルトの名無しさん
2008/08/14(木) 21:30:20そっとしといてやれ
0179デフォルトの名無しさん
2008/08/15(金) 01:25:52そんなことしたら、バッケンレコードを更新されるぞ。
面倒でも、構造化から教えてあげないと駄目なんじゃないの？
0180デフォルトの名無しさん
2008/08/15(金) 08:33:110181デフォルトの名無しさん
2008/08/15(金) 10:12:30○ おれら
0182デフォルトの名無しさん
2008/08/16(土) 08:06:48できない。
以前、真顔で「メソッドって2次入り口点なんですね」と言われたことがある。
プログラムが上から順番じゃなくて、呼ばれた順に実行されるというのも理解
できない。
それに、COBOLにあるのは変数じゃなくてレコードだから・・・変数の概念も
Javaとはだいぶ違うし・・・。
まさに>>178の言う通り。
0183デフォルトの名無しさん
2008/08/16(土) 09:00:42Javaだからとも云えるな。私は完全なコボラーだったけれど、
30才過ぎてからLispとPrologを難なく覚えた。この二つの言語は
COBOLと似たところが全くなく、かつ単純な構文要素しかないから
素直な初心者として学習できた。Javaだったらそうはいかなかった
に違いない。COBOLの知識から意味を理解しようとしてしまう部分が
少なくないのではないか。学習課題もCOBOLよりはるかに多い。
0184デフォルトの名無しさん
2008/08/16(土) 13:57:21とりあえず抽象データ型として教えるってことはできんのかな？
要するにカプセル化だけ。
抽象データ型は、普通の手続き型言語とも相性がいいと思うんだけど。
0185デフォルトの名無しさん
2008/08/16(土) 21:15:41確かにメモリ関係とか知らないのにオブジェクト指向分からんとか
言ってるのを見ると納得。
0186デフォルトの名無しさん
2008/08/17(日) 11:28:39http://imepita.jp/20080726/075540
0187デフォルトの名無しさん
2008/08/19(火) 18:28:35クラスとかメソッドとか、
要するに人様の作ったもんを使わせてもらうだけの話じゃないの？？
まあ、自分で作る場合もあるかもだけどさ。
単純に、文化の違いだよ。
0188デフォルトの名無しさん
2008/08/19(火) 22:20:31・選択条件だけに使ってるテーブル。
JOINから外して相関サブクエリ(EXISTS)にした方が良い。
EXISTSは1件見つけたら処理中止するから速い。
・トランザクションレコードに比べて件数が多いマスタとJOINしてる場合。
マスタの一部のレコードしか参照しないならスカラサブクエリにした方が速い。
SELECT句が冗長になるが、EXISTSと合わせ技で30分以上かかってた処理を10秒で終わらせた時がある。
0189デフォルトの名無しさん
2008/08/20(水) 10:51:42トランザクションレコードを用意してるってことは、
更新は夜間とかに一気にやるんだよね。それはいいと思うんだけど。
0190デフォルトの名無しさん
2008/08/27(水) 10:20:480191デフォルトの名無しさん
2008/08/27(水) 23:25:120192デフォルトの名無しさん
2008/08/27(水) 23:35:40仕事だもんな・・・ｗ
0193デフォルトの名無しさん
2008/08/28(木) 01:05:26なんでやらなきゃいけないのかも答えられないのか。
0194デフォルトの名無しさん
2008/08/28(木) 01:54:32本気なのか釣りなのかわからんが（以下略）。
0195デフォルトの名無しさん
2008/08/28(木) 09:52:05言われた通りに言われた事だけをやるのか。
テーブル別々に参照すればいいじゃないか。
なんで結合なんかしなきゃいかんのだ。
ＤＢなんだろ？ＣＯＢＯＬとかのファイルじゃないんだろ？？
レコード単位でしか見れないわけじゃないんだろ？
見たい、更新したいフィールドだけ、触ればいいのではないか？？
よけいな事しない方が速いだろ？
0196デフォルトの名無しさん
2008/08/29(金) 00:36:17在庫テーブル （品目コード、数量） と
品目情報テーブル （品目コード、名称、単価）
があって、在庫の一覧表（品目コード、名称、在庫額）を作りたい場合、
品目コードをキーに２つのテーブルを結合することを考えないか普通は？
0197デフォルトの名無しさん
2008/08/29(金) 09:52:57その例の場合、
在庫テーブルと、品目情報テーブルを読み込んで、
在庫の一覧表テーブルを、新しく作れば良くない？？
結合とか、余計な機能使ったら、遅くならないの？？
っていうか、在庫の一覧表テーブルを、新しく作っても遅いじゃん。
最初から、在庫の一覧表テーブルは用意しておいて、
在庫額だけ、数量ｘ単価を（プログラムで）計算して、更新すれば良くない？？
0198デフォルトの名無しさん
2008/08/29(金) 12:41:41在庫テーブルにはいつ追加、削除があるかもわからない。
在庫一覧テーブルを同時更新したとしても、最終的に、
在庫一覧表を表示する以前に一度は、
在庫一覧テーブルと在庫テーブル、品目情報テーブルの
整合性チェックをしなくてはならない。この事から、
在庫一覧表テーブルを用意しておいた方が速いとは必ずしも
言えない。
0199デフォルトの名無しさん
2008/08/29(金) 14:29:36> 結合とか、余計な機能使ったら、遅くならないの？？
結合はRDBの基本中の基本なんだが。
頼むから、COBOLの世界から出てこないでくれ。
間違っても、DB設計なんて手を出さないでくれ。
こっちも、そちらの世界には手を出さないから。
0200デフォルトの名無しさん
2008/08/29(金) 14:31:340201デフォルトの名無しさん
2008/08/29(金) 15:14:05整合性チェックが必要だよね。
在庫テーブル、
品目情報テーブルを、
在庫一覧表テーブルは最初から用意しておいて、
整合性チェックをした方がいいと思うけどなあ。
在庫テーブルが読めなかったら、
無条件で在庫一覧表テーブルの在庫額には、
０をセットすればいいじゃない。
障害が起こった場合、
追いかけるときにそういう作りにしておく方がいいと思う。
在庫一覧表テーブルは、最初から用意しといた方がいいと俺は思う。
最初から存在するテーブルを更新するだけなんだから、
それで速度が落ちるとも思えないなあ。
ただ、整合性チェックとかは、
プログラムでやらないといけないよね。
プログラムがわからないＤＢ技術者の人は、
そういうのイヤがるのはわかるな。
0202デフォルトの名無しさん
2008/08/29(金) 15:59:11「COMAL」
に変更することにしました。日本語で、hard to handleの意味で、委員全員の
賛成の下、2009年にも、名称変更することになりました。なーんちゃって。
0203デフォルトの名無しさん
2008/08/29(金) 16:13:15念のため商標登録しておきます。
0204デフォルトの名無しさん
2008/08/29(金) 22:17:25リアルに茶吹きそうになったじゃまいか。
0205デフォルトの名無しさん
2008/08/29(金) 23:57:21他にも、
購買契約テーブル（品目コード、購入先メーカーコード、購入年月日、購入数）
輸送契約テーブル（品目コード、輸送元コード、輸送先コード、etc）
日別在庫数遷移テーブル（品目コード、年月日、在庫数）
etc.
があって、それぞれ一覧表を作りたい場合、
購買契約一覧テーブル（略）
輸送契約一覧テーブル（略）
日別在庫数遷移一覧テーブル（略）
etc一覧テーブル（略）
を作るの？それらを全部リアルタイムで更新するの？
購買契約一覧テーブルは、品目名称だけじゃなくて、
購入先メーカー名称も必要だぜ。
0206デフォルトの名無しさん
2008/08/30(土) 00:52:130207デフォルトの名無しさん
2008/08/30(土) 01:01:42>プログラムでやらないといけないよね。
外部キー制約を設定すればいいんじゃない。
0208デフォルトの名無しさん
2008/08/30(土) 10:27:34＞購買契約一覧テーブル（略）
＞輸送契約一覧テーブル（略）
＞日別在庫数遷移一覧テーブル（略）
＞etc一覧テーブル（略）
＞を作るの？それらを全部リアルタイムで更新するの？
うん。作ればいいじゃん。
そういうめんどくせーのはＰＧ的じゃないという意見もわからなくはないけど、
めんどくせー事をめんどくさがんないでやった方がまちがいが少ないよ。
リアルタイムで更新するかどうかは、データ量によると思うけど・・・。
トランザクションを持っといて、
夜中とかにまとめてバッチ処理してもいいし。
その方が普通かな。
＞購買契約一覧テーブルは、品目名称だけじゃなくて、
＞購入先メーカー名称も必要だぜ。
そんなの購入先メーカーコードをキーにして引っ張ればいいだけでしょ。
また整合性チェックすればいいんだよ。
めんどくさがらないで。
＞外部キー制約を設定すればいいんじゃない。
それもそうだけど、
プログラムで整合性チェックして、読み込めなかった時は、
メッセージ出すとかした方が、運用の人にやさしくない？
0209デフォルトの名無しさん
2008/08/30(土) 18:49:39>在庫一覧テーブルと在庫テーブル、品目情報テーブルの
>整合性チェックをしなくてはならない。この事から、
>在庫一覧表テーブルを用意しておいた方が速いとは必ずしも
>言えない。
ＳＱＬ文で一発で行えるにしても、
内部的には整合性チェックを行っている。
外部キー制約を設定するにしてもそう。
整合性チェックはプログラムで行い、
最初からテーブルを用意して、更新のみ行う方が速い。
最初から用意されているテーブルを更新するだけの方が速いのは自明の理。
それに、ＳＱＬの機能に頼らないで、
自力でプログラムで整合性チェックを行い、
結果をログやメッセージ等で追いかけられるようにしておけば、
運用、保守の面でも良い。
いろいろ勉強して、試してみたい気持ちをわかる。
それは、好きで仕事をしているんだから、大切な気持ちだ。
だけど、仕事はそうじゃない。
0210デフォルトの名無しさん
2008/08/30(土) 19:37:42,.∩ ｀ヽ
〃∪'´￣｀二二人＼ ヽ
| ツ´￣￣￣￣´ ヾ ヽ. ',
|ﾊ ,ニ、 ,. - ､ | | | l |
| ﾊ ｨハ ,二ヽ. | | | | | 同じ板にコピペするとそのままだけど、
| | | じ' |トJ〉 /)} l | 違う板にコピペすると鬼のような怖い顔
| ﾊ ､'＿, ￣,, 厶ｲ川| に変わる摩訶不思議な佳子様コピペ。
l l /＼ .. イV＼川 |
,' l l ,ｲ ｀l￣´ ／ /ヽl l
l | l ハ `メ､ 〃 ヽヽ､__ノ
l ∨ └‐ｲ「ト--ｧ'´ ﾊヽ__ノ
ヽ/ } l」」 / / }`ー
〈_n| 八 / / /ノ
〈二二人 c /＼/ / , ｲ
/ /厂 ／＼__>< ｛＿
0211デフォルトの名無しさん
2008/08/31(日) 00:13:32あんたみたいのがいるから、IT技術者の地位が低下するんだ。
さっさと消えてくれ。
0212デフォルトの名無しさん
2008/08/31(日) 10:15:54>結合とか、余計な機能使ったら、遅くならないの？？
>>196 の例ならば、たいして遅くならない。
select
Z.品目コード, H.名称, Z.数量 * H.単価
from
在庫テーブル Z left join 品目情報テーブル H
on
Z.品目コード = H.品目コード ;
在庫テーブルも品目情報テーブルも、品目コードがプライマリキーであることは明らかだから、結合キーが品目コードだけの上記SQLは十分速い。
>在庫テーブルと、品目情報テーブルを読み込んで、
>在庫の一覧表テーブルを、新しく作れば良くない？？
良くない。そんな事する方が圧倒的に遅い。
誤解しないで欲しいのだが、俺は別にSQL結合マンセーではない。場合によっては、>>197 の主張するとおり、中間的なテーブルを設けて処理する方法もアリだと思う。しかし、>>196 のような単純な例では、
中間テーブル方式 ＞＞＞＞ SQLで必要情報を結合して取得する方式
コストを比較すればこうなる。
もし、在庫一覧表出力機能あるいはそれに類する物を設計する機会があるなら、中間テーブル方式にせよ、SQL結合方式にせよ、状況（データ構造、更新頻度、etc）によって適切な方式を選択する必要がある。
しかし、>>197 はどうも、SQLの結合に対して妙な偏見があり、無条件に中間テーブル方式を採用してしまうような気がする。技術者として、その姿勢にはいささか問題があるよ。
0213デフォルトの名無しさん
2008/08/31(日) 10:20:55正直、現代においてはアフォなCOBOLerのつくったプログラムに
どれだけの人間が泣かされているか認識してほしいな。
まともな仕事してからCOBOLerは発言して欲しいな
0214デフォルトの名無しさん
2008/08/31(日) 10:44:30ちゃんと読んどくれ。
いちいち作ったら遅いよ。そりゃそうだよ。
だから、「最初から作っといてソレを更新する」っていうお話。
それと、ログとかメッセージとか取ろうよっていうお話。
異常終了した時とか、プログラムで落ちた時の状態を取っとけるといいじゃない。
0215デフォルトの名無しさん
2008/08/31(日) 10:51:36めんどくさいけど。
結合で毎回作るより速いでしょう。
プログラマ的でないと言う意見はわかる。
でも仕事だし。
趣味だったら、いろいろ凝るべきだと思う。
0216デフォルトの名無しさん
2008/08/31(日) 11:14:07＞結合で毎回作るより速いでしょう
俺もちゃんと読もう。
＞しかし、>>197 はどうも、SQLの結合に対して妙な偏見があり、
＞無条件に中間テーブル方式を採用してしまうような気がする。
＞技術者として、その姿勢にはいささか問題があるよ。
最初から結合した結果の項目を持ったＤＢ用意しとけばいいと思うんだけどなあ・・・。
そうだね。しょっちゅうは参照しないから、
いちいちＤＢは作りたくない場合なら、結合の方がいいよね。
でも、頻度が高いのなら、めんどくさいけど最初から作っておいた方がいいと思う。
速度が気になるというお話ですし・・・。頻度は高いのかと。
0217212
2008/08/31(日) 12:13:50以下2方式を比較してみる。
(a) 検索毎に必要なテーブルを結合しつつselectして、一覧表を出力する
(b) 事前に中間テーブルを作っておいて、それを単純にselectして一覧表を出力する
●比較その１、
「在庫一覧表出力ボタンをクリックしてから、一覧画面なり帳票なりが出力完了するまでの時間」
(a) ＞ (b)
●比較その２
「一覧表出力以外の部分に要するコスト（在庫更新時のオーバーヘッドなど）」
(a) ＜ (b)
もし、「在庫一覧表はとにかく最高速で出るようにしてくれ！そのためにオンライン業務の在庫更新などが遅くなっても構わん！」
という業務用件であれば、方式(b)を選ぶべきである。
しかし現実にはそんなことは無い。在庫チェック担当者は、在庫一覧表が速く出る方が良いけれども、在庫の入出庫担当者は、在庫更新業務を速くしてくれ、と言うだろう。
そこで両方式の利点、欠点を秤にかけた上で、
「方式(a)の欠点である、検索時の速度低下は、今回のケースではそれ程でもない。ゆえに、(b)のコストを回避して、方式(a)を採用した方が、全体としてユーザーの満足度は向上する」
というのが>>212での主張である。
中間テーブル作るのが面倒だから(b)を回避するのではない。
0218デフォルトの名無しさん
2008/08/31(日) 13:48:26在庫テーブルと品目テーブルにトリガを付ければいいんじゃない。
在庫テーブルと品目テーブルにトリガを付けて、
在庫の一覧テーブルを最新の状態に保とう、
ってことと同義でしょ。
0219デフォルトの名無しさん
2008/08/31(日) 15:48:18>●比較その１、
>「在庫一覧表出力ボタンをクリックしてから、一覧画面なり帳票なりが出力完了するまでの時間」
> (a) ＞ (b)
最新の状態に常に保たれていれば
ａ＜ｂじゃないかな。
そうですよねえ。
もともとのお話は、かなり処理に時間がかかっているとの事ですので・・・。
トリガを使うと、それはそれでやっぱり遅いかもですよねえ。
そうかといって、バッチ処理だと、
最新の状態は、常に保てないですよね・・・。
（そこが問題だからご指摘いただいてるんですよね）
そうなると、結合を使ったほうが良くなるね。
でも、それだと在庫の一覧テーブルいらないよね。
っていうか、
在庫の一覧テーブルが、
在庫テーブルと品目テーブルの項目を両方網羅してるんだから、
在庫テーブルと品目テーブルそのものがいらないんじゃん？？
そもそも、在庫が０になったら、
在庫テーブルをデリートするもともとの設計が悪いよ。
0220デフォルトの名無しさん
2008/08/31(日) 15:55:19設計を見直すべきだと思うよ。
そもそも、結合よりも
在庫の一覧テーブルを作った方がいいと思うのも、
そういう理由だし。
好きで、勉強していろいろやりたいのはわかる。
でも、最近の若い人は、機能がない事をすぐ言い訳にするから、
あんまりＳＱＬとかの機能に頼るのは好かんのだよなあ・・・。
そういうと、若い人からコボラーだとかジジイだとか言われるんだけどさ。
0221デフォルトの名無しさん
2008/08/31(日) 18:36:03それがいやなら、最初からRDBなんて使わなければ良い。
まずは正しく設計をした上で、性能が出ない部分にadhocな処理を加えるのが筋。
そんな簡単なことが守れないから、コボラーの作るDBは保守不可能となる。
0222デフォルトの名無しさん
2008/08/31(日) 18:36:59「SQLの機能に頼るのは好かん」とか
言うのは微妙だけどなー。
基本的にはRDBMSを熟知してから、設計＆実装し
それでも足りない機能があるならプログラムするってのは
わかるけど、COBOLerはRDBをファイルと同程度に
しか認識していないところがウザい。
0223デフォルトの名無しさん
2008/08/31(日) 19:47:57うんうんそうだね
勉強は大切だよ☆
0224212
2008/08/31(日) 20:20:49>最新の状態に常に保たれていれば
>ａ＜ｂじゃないかな。
？？？
>>●比較その１、
>>「在庫一覧表出力ボタンをクリックしてから、一覧画面なり帳票なりが出力完了するまでの時間」
>> (a) ＞ (b)
この不等号は、「(a)の方が多くの時間がかかる（遅い）」という意味だぞ。
>っていうか、
>在庫の一覧テーブルが、
>在庫テーブルと品目テーブルの項目を両方網羅してるんだから、
>在庫テーブルと品目テーブルそのものがいらないんじゃん？？
品目情報テーブルをなくしてしまったら、 >>205 の例に挙がっているような、品目を使う全てのテーブルに、必要に応じて名称やら単価やらを持たせる必要がある。
それである日、ある品目の単価が変更になったとしよう。単価あるいは金額を保持する全てのテーブルをそのタイミングで更新する必要がある。
またある日、ある品目の名称が変更になったとしよう。・・・・・（略）・・・
昔、マシンの性能が非力だった時代には、SQLでちょっとでも複雑なことをやろうとするととたんに速度低下をきたしたので、上記のような非正規化の設計にも意義があった。
しかし、今はそんな心配は無い。上記の非正規化設計によって得られるメリット
「検索時に速くなる」
なんてのははっきり言って極小であり、それよりも、デメリット
「更新時の煩雑さ」
の方がはるかに深刻である。
重ねて言うが、俺も、変に凝ってSQLのテクニックに溺れるようなのは問題だと思う。
しかし、更に重ねて言うが、>>212 で挙げたようなSQLは、ぜんぜん凝ってなどいない。ごく基本的、シンプルなSQLだ。これを見て「懲りすぎ、テクニックに溺れている」なんて言うならば技術者として問題だ。
0225デフォルトの名無しさん
2008/08/31(日) 23:40:54あのさー…。
君の言ってることって、
RDBMSが理解ができない新人のヘリクツ、
って風に映るんだけど。
今まで自分が書いたレスを読んでごらんよ。
とても思慮が浅く、無知であることが分かるでしょう。
すこしは勉強なさい。
0226デフォルトの名無しさん
2008/09/01(月) 05:24:41長いこと保守していて、それに誇りを抱いているんだろうな。
俺がいまちょっと関わっているシステムもそんな感じだ。
○○情報
××展開○○情報
△△履歴××展開○○情報
こんな感じのテーブルが腐るほどあり、大きなものだと項目が300近くあり、
しかも改修案件ごとに今でも項目が追加されている。
しかも、「◇◇区分」という項目を取得したい場合、たいがい、
３つぐらいのテーブルがその項目を持っている。
「ほとんどの場合」、その３つのテーブルは、同じ値の「◇◇区分」を持っているが、
処理の流れ、業務の綾によって微妙に異なる場合もあるらしく、
そういう時は、長年たずさわってきた重鎮の人に聞くわけさ。
「その場合は、××展開○○情報から取ってきた方がいいね」
『彼』ならこう言うだろうね。
「それが仕事だろ。趣味じゃないんだから」
「面倒臭がらずに、××展開○○情報とか△△履歴××展開○○情報とか保守すればいいじゃん」
それはやむを得ず行うことであって、決して望ましいことではない、
と『彼』に伝えるにはどうしたらいいだろうか？
0227デフォルトの名無しさん
2008/09/01(月) 07:53:08最近のDBMSはハッシュ結合とかできるから結合が結合なしより遅いとは限らない。
寧ろ索引ついてない項目走査すると結局全列物理読出しするからその方が遅くなりうる。
仕事で面倒くさがるのは逆説的だが正しいと思う。
面倒くさいことを機械にやらせるためにシステム屋が存在するのだから。
0228デフォルトの名無しさん
2008/09/01(月) 08:50:34人はミスを犯すという観点から見たら、正規化するのが第一選択肢
そういう視点がないとしたら、システム屋として失格だろ
0229デフォルトの名無しさん
2008/09/01(月) 09:59:03そうだね。そんなに遅くならないんだったら、
テーブルを分けたほうがいいよね。
ラクするのは客で、システム屋がラクするのはちょっと違うんじゃね？
（今度はどんな事いいだすかな？）
0230デフォルトの名無しさん
2008/09/01(月) 10:00:08いっぱい機能がつかえるもんね☆
0231デフォルトの名無しさん
2008/09/01(月) 10:11:26もしかして、この話>>154あたりが起点なの?
0232デフォルトの名無しさん
2008/09/01(月) 10:40:37俺もそう思います☆
やり方がシンプルなほど、まちがいは少ないのです。
0233デフォルトの名無しさん
2008/09/01(月) 10:52:160234デフォルトの名無しさん
2008/09/01(月) 10:53:200235デフォルトの名無しさん
2008/09/01(月) 10:57:48＞最近のDBMSはハッシュ結合とかできるから結合が結合なしより遅いとは限らない。
＞寧ろ索引ついてない項目走査すると結局全列物理読出しするからその方が遅くなりうる。
＞仕事で面倒くさがるのは逆説的だが正しいと思う。
＞面倒くさいことを機械にやらせるためにシステム屋が存在するのだから。
そういう言葉を並べると素人はごまかせるけど、
言ってるコトはスゲーあいまい
ごまかしてはいけない。
あえて、平易な言葉と処理でなんとかするべきなのだ。
お前らみたいのがいるから、
客をだますインチキ商売だと誤解されてしまうのだ。
0236デフォルトの名無しさん
2008/09/01(月) 12:11:350237デフォルトの名無しさん
2008/09/01(月) 14:01:24＞「検索時に速くなる」
＞なんてのははっきり言って極小であり、それよりも、デメリット
＞「更新時の煩雑さ」
＞の方がはるかに深刻である。
彼に言わせれば、平易ではなく、煩雑らしいぞ。
品目が違えば、単価も違って当然でしょう。
品目が同じで単価が違うレコードはありえないんだから、
キー項目は、品目だけでしょ。
そんなに煩雑とも思えないけど・・・。
＞昔、マシンの性能が非力だった時代には、SQLでちょっとでも複雑なことをやろうとすると
＞とたんに速度低下をきたしたので、上記のような非正規化の設計にも意義があった。
どうしたら速くなる？っていう話なんだから、その通りだよ。
別に遅くならないんだったら、結合使ったっていいんじゃない。
＞重ねて言うが、俺も、変に凝ってSQLのテクニックに溺れるようなのは問題だと思う。
＞しかし、更に重ねて言うが、>>212 で挙げたようなSQLは、ぜんぜん凝ってなどいない。ごく基本的、シンプルなSQLだ。これを見て「懲りすぎ、テクニックに溺れている」なんて言うならば技術者として問題だ。
テクニックに溺れるのは良くないよ。
それをわかってくれていれば、いいと思うよ。
0238デフォルトの名無しさん
2008/09/01(月) 14:05:41一見難しい言葉と、あいまいな表現は、
いくらでも逃げられるからな。
どっちつかずな事を言っておけば、
自分は追及されることがない。
機械はあいまいな事を言われても動かない。
重ねて言う。ごまかしてはいけない。
あえて、平易な言葉と処理でなんとかするべきなのだ。
お前らみたいのがいるから、
インチキ商売だと誤解されてしまうのだ。
0239デフォルトの名無しさん
2008/09/01(月) 14:07:06そっちの方が技術者としてよっぽど問題だよ。
0240デフォルトの名無しさん
2008/09/02(火) 00:16:57両方やった俺が来ましたよ。
素データが x個集まって小隊
小隊が y個集まって中隊
中隊が z個集まって大隊
・・・・
てな風に、あるデータは上位データの構成要素、
という構造のデータを扱う局面に限ればCOBOLの方が書きやすい。
（ただし、上記の例ではx,y,zの値が固定であることが前提。
可変にしようとするとCOBOLでは無理。たぶん）
0241デフォルトの名無しさん
2008/09/02(火) 02:59:04皆が言っていることは、
必要としている機能を、
RDBMSが有しているのだからRDBMSの機能を使う。
ということ。
対し君は、
自分で作るべき。
と主張している。
｢既に開発、テストが済んでいる機能｣
と
｢新たに開発、テストを行う機能｣
どちらを採用するか、
という問いに、
皆は｢開発済み｣を選択し、
君は｢新規開発｣を選択している。
君は、
期間を要する方、
バグの危険性の高い方を選択している。
不自然だろ。
0242デフォルトの名無しさん
2008/09/02(火) 07:38:45>やり方がシンプルなほど、まちがいは少ないのです。
その通り！
大量の非正規化テーブルをこしらえて毎回整合性をとらせるとか、
表示用の中間テーブルをこしらえて毎回整合性をとらせるとか、
そんな仕組みをシコシコ自前で作るより、RDBMSのリレーションの機能を活用して、
シンプルに情報を結合して取った方が、まちがいは少ないのです。
0243デフォルトの名無しさん
2008/09/02(火) 10:04:32>と
>｢新たに開発、テストを行う機能｣
>どちらを採用するか、
>という問いに、
>皆は｢開発済み｣を選択し、
>君は｢新規開発｣を選択している。
>君は、
>期間を要する方、
>バグの危険性の高い方を選択している。
>不自然だろ。
どうしたら速くなるか？っていうお話だよ。
設計を見直すべきだというお話。
この例では、別に複雑ではないが、
継ぎ足し、継ぎ足ししていると、
そのうちに手が入らないシステムになってしまう。
まあ、その方がカネが取れるといえばそうだけど、
そういう技術者ばかりだからダメなんだよ。
設計に良くない部分があるのなら、
早めに見直すべきだ。
何度も言うが、プログラムや機能より、設計。
結合の方が技術者は確かにラクでバグは少ないけど、
面倒くさがってはいけないよ。
その程度でバグ出す心配してるようじゃダメだよ。
0244デフォルトの名無しさん
2008/09/02(火) 11:47:30なおさら機能に頼るクセなくさないとスキルがあがらないよ。
そんな修正くらいでバグ出す心配するようだったら
意見なんかしちゃダメだよ。
0245デフォルトの名無しさん
2008/09/02(火) 17:00:200246デフォルトの名無しさん
2008/09/03(水) 01:38:06>設計を見直すべきだというお話。
その設計とやらが、
SQLによる複数テーブルの結合によるレコード取得を否定し、
複数テーブルから個別にレコード取得する方式を指し、
外部キーによる整合性の維持を否定し、
プログラムからの整合性チェックを指すならば、
それを設計とは誰も呼ばない。
それはムダと呼ばれ排除する為に皆が努力を重ねている。
それに対し君は、
そのような努力を怠る自らを慰める言い訳を探すかの如く、
皆の考えを否定する。
君は間違っている。
0247デフォルトの名無しさん
2008/09/03(水) 01:49:50ケースバイケースが結論じゃないかな。
コーディング規約守ってると性能出ない時に性能優先する文脈なんだから。
ただ間違いなく「COBOLで全部作る」のは「DBMSの機能を利用する」より性能遅い。
今時のオプティマイザに勝てるコードを書ける人間ならCOBOLやるよりアナゴってるだろ。
0248デフォルトの名無しさん
2008/09/03(水) 04:02:36実行計画は見たのか？
0249デフォルトの名無しさん
2008/09/03(水) 10:55:59それは212氏とのやりとりで俺は237の書き込みで言っている。
>>246はちゃんと読め。
ちゃんと読んでない上に感情的だ。
最初に２つの表から、１つの表に移行する時に、
プログラムでやって、整合性チェックは必要だけど、
（まあそれも別に結合でやってもいけなくはないけど）
１つの表にしちゃってれば、速いでしょ。
自分たちが機能を使ってラクする事を、
ムダを省くって言ってるだけだろ。
>>247
そりゃ、ケースバイケースだと言われちゃうとなあ。
ＤＢの機能を利用しなきゃいけないようなファイルの持ち方をしていて、
コーディング規約とか、客の要望でどうにも変えられないようなら仕方ない。
そういう場合は、機能を使った方が速いよ。
それはそうとして、
ファイルの持ち方は、よく考えるべきでしょう。
ファイルの持ち方をシンプルにすれば、速くなるはずだよ。
0250デフォルトの名無しさん
2008/09/03(水) 10:58:38＞と
＞｢新たに開発、テストを行う機能｣
＞どちらを採用するか、
＞という問いに、
＞皆は｢開発済み｣を選択し、
＞君は｢新規開発｣を選択している。
＞君は、
＞期間を要する方、
＞バグの危険性の高い方を選択している。
＞不自然だろ。
コレって、君たちがバカにしている、バカコボラーの発想じゃないの？
それじゃバカにされてもしようがないだろ。
0251デフォルトの名無しさん
2008/09/03(水) 11:31:08もういじめないよ。
ごめんね☆
0252デフォルトの名無しさん
2008/09/03(水) 11:32:57■ このスレッドは過去ログ倉庫に格納されています