「COBOLコードの近代化はどのように進めるべきか」記事へのコメント

負の遺産ってねぇ、あーた

[Anonymous Coward]

プログラム自体は継承していく必要なんて無いじゃんか。
価値があるのは(継承すべきは)データだけだよ。
つまりデータフォーマットさえ解れば大した問題じゃないってこと。
データフォーマットが解らないとしてもCOBOLのせいじゃないよね。
負の遺産って人間の不手際をCOBOLのせいにされているようで気の毒だな。
なんで毎度ネタになるんだか。

Re:負の遺産ってねぇ、あーた

[gigo (21150)]

データベースは詳しくないのだけど、データとロジックを簡単に分けられないというか、RDBならば表（データ）の設計の時にやることとがいちいちロジックで書かれているので大変なのではないですか。

今のようにRDBが普及していれば、仮にDBMSを使わなくても、正規形はどうだとか、どういうのが良いデータの構造なのかとか考えながら作ると思うけど、そのような予備知識も無くて作っていて、同じようなデータがプログラムのあちこちにあるとか、わずかな実行時間の節約のために変な参照をしているとかは考えるだけで憂鬱になります。

Re:

[Anonymous Coward]

>正規形はどうだとか、どういうのが良いデータの構造なのかとか考えながら作ると思うけど、そのような予備知識も無くて作っていて

甘いorz
DQNな現場では実際Oracle使っていてすら、
正規形どこ吹く風な使い方を平気でやってくれる。

1日1カラムで366カラム(閏年考慮)有るテーブルとか、
それに更に年単位の情報を持つカラムを直接つけて367カラムになってるとか。
更に月単位まで同居してるから379カラムとか、
更に別件の情報まで別テーブルにせず同居してるから更に多かったりとか、
そんなの茶飯事orz

もちろんデータは冗長になり、
データ同一性が怪しげになったり、
速度も落ちたりする。
もちろん理解もし辛い

Re:負の遺産ってねぇ、あーた

[Dobon (7495)]

昔のOracleにはカラム数２５５の縛りがあったけど、今は無いからな……。
正規化しなくても、遅くならないし。

このため、DQN構造のＤＢが増殖する。あたまいたいです。

--
notice : I ignore an anonymous contribution.

Re:

[Anonymous Coward]

> DQN構造のＤＢが増殖する

鯖の能力があがってストレージが湯水と化してDQN増殖を助長してるのだから
頭痛解消なら能力小さい、ストレージ貧な鯖をチョイスすべし（笑）