22:37:48前スレです。04:22:12>>3未来なきJavaなど冒涜する気にもならない。22:42:55純粋にCOBOL、JAVAを比較して(レガシーアプリなし、新規構築という条件)COBOLが優れている点ってないのかな。今のとこ"vs"って内容になってない気がする。入出力すべてシーケンシャルファイルのバッチプログラムを数十段も連ねて、一番最後にDBにロードして、、、ということやっていた。処理速度で悩まされることが多い。SQLをチューニングして何とかなる場合は、それでいいんだが、DBMSの諸々の設定(あるいはバグ)の問題が絡んでくると厄介。昔は良かったなぁ、と思うことがよくある。圧倒的にCOBOLが作りやすい。しないとまともな仕事ができない。しまくった複雑なSQLが、処理速度を落としている。>主観的には、昔のCOBOLの多段バッチAPなら>5本を組み合わせて行うボリュームの処理を、>たった1つのSQL、1つのAPで行おうとしている感じ。漏れ、ABAA??ABB9みたいなテーブル数10個以上で正規化もクソもない多段バッチのCOBOLのプログラム見たことあるけど。いう糞設計もCOBOLerが独壇場に感じる。それにテーブル10個JOINしないと、の件もフカシが入っていると思うが。本気だとしたら、それこそコボラーかAccessヲタが設計したんだろう。ちなみに昔の人でもいい設計する人はいる。COBOLと言う言語自体は全否定はしないが実際に許せるレベルの設計できる人は万分の一程度だろうなぁ。Java+SQL(簡単)悪いんだが、処理速度の改善策としてこんな悪手を選択するエンジニアが「COBOLの方式もよい」なんて発言するって事はRDBMSの基礎も解っていない素人にしか思えん。09:52:57そうか。在庫の一覧表テーブルを、新しく作れば良くない??結合とか、余計な機能使ったら、遅くならないの??っていうか、在庫の一覧表テーブルを、新しく作っても遅いじゃん。例ならば、たいして遅くならない。;在庫テーブルも品目情報テーブルも、品目コードがプライマリキーであることは明らかだから、結合キーが品目コードだけの上記SQLは十分速い。>在庫テーブルと、品目情報テーブルを読み込んで、>在庫の一覧表テーブルを、新しく作れば良くない??良くない。そんな事する方が圧倒的に遅い。誤解しないで欲しいのだが、俺は別にSQL結合マンセーではない。主張するとおり、中間的なテーブルを設けて処理する方法もアリだと思う。SQLで必要情報を結合して取得する方式コストを比較すればこうなる。それに類する物を設計する機会があるなら、中間テーブル方式にせよ、SQL結合方式にせよ、状況(データ構造、更新頻度、etc)によって適切な方式を選択する必要がある。SQLの結合に対して妙な偏見があり、無条件に中間テーブル方式を採用してしまうような気がする。技術者として、その姿勢にはいささか問題があるよ。11:14:07ああごめんなさい。作るじゃなくて引っ張るですよね。>結合で毎回作るより速いでしょう俺もちゃんと読もう。SQLの結合に対して妙な偏見があり、>無条件に中間テーブル方式を採用してしまうような気がする。>技術者として、その姿勢にはいささか問題があるよ。最初から結合した結果の項目を持ったDB用意しとけばいいと思うんだけどなあ・・・。参照しないから、いちいちDBは作りたくない場合なら、結合の方がいいよね。頻度が高いのなら、めんどくさいけど最初から作っておいた方がいいと思う。速度が気になるというお話ですし・・・。10:04:32>「既に開発、テストが済んでいる機能」>と>「新たに開発、テストを行う機能」>どちらを採用するか、>という問いに、>皆は「開発済み」を選択し、>君は「新規開発」を選択している。>君は、>期間を要する方、>バグの危険性の高い方を選択している。したら速くなるか?っていうお話だよ。設計を見直すべきだというお話。継ぎ足し、継ぎ足ししていると、そのうちに手が入らないシステムになってしまう。その方がカネが取れるといえばそうだけど、そういう技術者ばかりだからダメなんだよ。何度も言うが、プログラムや機能より、設計。面倒くさがってはいけないよ。その程度でバグ出す心配してるようじゃダメだよ。01:38:06>>243>設計を見直すべきだというお話。外部キーによる整合性の維持を否定し、プログラムからの整合性チェックを指すならば、それを設計とは誰も呼ばない。それはムダと呼ばれ排除する為に皆が努力を重ねている。