何故データベース設計は軽視されるのか？

1 ：08/12/01 〜 最終レス ：11/12/04

何故データベース設計は軽視されるのか？
ここでいうデータベース設計とは、
特定の業務システムにおける
テーブルレイアウトを設計し、決める作業であるとします。
業務システムにおいては、
このデータベース設計（テーブル設計）は仕様そのものを定義する作業にも
近いと思いますし、この設計は開発工程やその後の運用における品質を
絶対的に左右するものだと思っています。
逆にこの設計があまりにも実現すべき仕様と比較し不整合なため、
その後の開発工程がデスマーチに陥ることも少なくないのではないでしょうか？
にも関わらず、正規化程度も理解できないような担当者が
この設計を行っていたり、業務システムの受託開発において、
「テーブルレイアウトを決める」という作業が、あまりにも軽視されているような
気がしています。
みなさんの現場ではどうでしょうか？
ご意見などお聞かせください。

2 ：

ここでいうデータベース設計とは、テーブルレイアウトを決める作業を指し、
データベースとは、リレーショナルデータベースを指しています。

3 ：

プログラムのデザインも、正規化も知らない奴がSEを名乗ってるからだろ。
驚くぐらい何も知らない。

4 ：

むしろDBの設計でPGが大きく変わって組みやすくなる可能性もあるというのに・・・・
確かに>>3の言う通りだと思う

5 ：

ERDのこと？

6 ：

とりあえず今保守してるシステムのテーブル名とカラム名に
日本語を使ってるのやめさせたい。それからコボラーの薫陶を
受けたVBA使いの作ったシステムを全て作り直したい。

7 ：

動きゃいい、と思ってるからですかね。

8 ：

>>7
動けばいいとすら思ってない。
作って納品しちまえばおｋと思ってるw

9 ：

納品時のテストデータでかろうじて動作はするものの
本運用に入ったら誤作動しまくり落ちまくりってのはもう
狙ってそう組んでるとしか思えなくなってきた・・・

10 ：

いまだに綱渡り的な設計とかが存在してるのな(；´∀｀)

11 ：

いまだに「テーブル名・カラム名は全てID制です！」ってとこもあるからな。
IDが何なのかってのを記憶してる人間が技術力高いつて重宝されとる……

12 ：

そろそろ今のPJが終わるので今度入る予定のPJチームに挨拶行った。
若手のSEがDB設計中だったので覗いたら、テーブル名・カラム名を日本語で書いてる・・・
んで、それはやめようよと言ったら、マニュアルのどこにダメって書いてあるんですか！日本語は使えるはずですよね！
と言われたので、その場でPJから外してもらうよう上司に頼みに行った。
送り仮名で嵌るんだよ・・・

13 ：

SYOHIN
SHOHIN
SHOUHIN
前任のアフォが設計したDBでこれらが混在してたから
全部「商品」で統一して新規で作り直す仕事何べんもやってるw

14 ：

ど素人でＤＢに興味あるものですが、
このスレ読んでおれもＤＢ設計してみようかなと思った

15 ：

つうかね会社の方針が変わったり条例が変わったり法律が変わったりするたびに変更しなきゃならないシステムもたくさんあるわけよ
そのたびに一から作ってたら間に合わんし客も予算出せないでしょ
実稼働中の物を今日まではこれ、でも明日からはこのシステムで
なんて無茶な用件はたくさんある
だからある程度の遊びフィールド作ったり妙な拡張して過去の残骸が残ってたりする物が出来てくるわけ
それを最初見た奴にとっては謎いシステムかもしれないけどさ
簡単に言うとガチガチに設計すると馬鹿を見る事も多いんだよ

16 ：

>>15
コボラ？

17 ：

>>1
データベース屋がまともな仕事をしないからだろ。
>>3のような技術力の不足、利用シーンを考えない独り善がりな設計など。
むやみに正規化してりゃいいってもんじゃないし。

18 ：

とりあえず
2008/11/12
を画面上でH.20.11.12
とかで表現するのはいいけど
DBにまで
H.20.11.12
として保存する仕様は勘弁してください。

19 ：

>>18
そんなのまだまし。
3601112←これ昭和60年な
3201112←これ平成20年な
4011112←これ西暦2001年な
和暦は3で西暦は4な。

20 ：

>>19
平成22年とベビーブームが始まる昭和22年はバッティングしないのでせうか( ﾟдﾟ)

21 ：

>>20
生年月日とかでなければバッティングしないんじゃない？
それにしても、その仕様は無いなw

22 ：

そういえば、社会保険庁が提供している申請用ソフトも
データが和暦格納で使いにくいな。
スレとは関係ないけど、そいつが吐き出すCSVはクォーテーションが付いてないので
うっかりExcelなんかで開くと、コードの頭のゼロが取れていたりする糞仕様。(0001→1)

23 ：

>>22
心配するな。「"」付きでもExcelはゼロサプレスしてくれるよ。
んで、うっかりExcelで開いて保存しちゃったCSVを本番に突っ込んじゃった
アホがいたもんだから、マスタが一切引けなくなってえらい目にあった。
…DB設計の問題じゃないけど。

24 ：

>>20
バッティングする。しかし詳細はばれるので明かせないが、３０年の期限が
管理できればいいので、生きてるデータは最古でも1978年。
死んでるデータはもうグダグダ。ゴミ。

25 ：

>>22
可能です。
以上。
↓次どうぞ

26 ：

>>1
経営者や管理職や客は、目に見えるものしか評価できないから、
DB屋よりもJava屋の意見を聞く。
↓
Java屋は、O/Rマッパを使いまくって、DBをオブジェクトの永続化ストレージ
としか考えない。DB設計？なにそれ？おいしいの？
↓
それでも動く。
↓
Java屋
「ほら見ろ、俺のやり方が正しい」
「DB屋の言うことなんか聞いてたら開発おわんねw」
↓
数年後： DBあぼ(ry
↓
開発当時の人間いない。だれのせいか分からない。
DBがダメになったから、DB屋が悪かったに違いないという判断。
↓
DB屋、ますます発言力低下。
↓
以下、ループ。

27 ：

DB屋が論理設計途中でトンズラされたPJ。
既に実装スタートしてたから皆でオンデマンドでDB設計やってたぜw

28 ：

>>19
明治は１，大正は２，昭和は３，西暦は４，
てなのを大昔にコボルさんが組んでて、
昭和天皇の崩御で困った困ったって話？

29 ：

>>19
つっか、マジな話、
今の天皇が幾久しく健康でありますようにと、お祈りする必要があるね。

30 ：

>>28
まさに文系乙の、非論理的な設計ですね。
文系の声がでかいのも、論理的な正しい設計が軽視される原因と見た。

31 ：

>>30
文系とか関係ないだろ。見通しの甘さが全ての原因だ。
ようするにバカなんだよ。

32 ：

ＳＥの机にデーターベース入門とか並んでて吹いた

33 ：

まあ、たしかにＤＢ屋の地位とかは低いよな。。
俺は運用側なので、開発側が主催する
システムリリースの打ち合わせに呼ばれる。
開発側の説明を受けた後で、運用上、設計上の問題をあげ、
改定を提案すると、いつも返答はこれだ。
「リリースしないと業務に支障がでる！」
だったら、システム設計のころから打ち合わせに呼べよ。
割を食うのはいつもこっちだ。
すまん、愚痴った。

34 ：

年月日を和暦で格納するとか、
カラム名が日本語や日本語をローマ字にしたものであるとか、
運用を続けていくうえで仕様変更が続き過去の残骸データが残っているとか、
このあたりはもうしょうがないというか、諦めています。
我慢できます。
問題にしたいのは、論理性（純粋な意味での設計）です。
例えば1対nの関係にある情報を2テーブルに格納すべきところを
1側の情報を多側にn個格納したり、
候補キーが不十分で対象のレコードを特定できないケースがあるテーブルがあったり、
日々追加削除が発生するテーブルが第3正規形になっていなかったり、
（ケースバイケースがあることは承知しています）
こういった問題のほうがデスマーチに陥りやすいと思います。
で、デスマーチに陥ったら陥ったで何故かプログラムで対応しようとする。
設計に立ち戻らないんですね。ここが問題だと思っています。

35 ：

建築に例えれば、DBとかネットワークは土台、地盤にあたる部分だよね。
それが緩い、いい加減なところの上でシステムを構築することが、
いかにリスクが高いか、判らないのかねぇ。
判らないんだろうなぁ。
システムは目に見えないからねぇ。

36 ：

この板には最近来るようになった新参者ですが
このスレは書き込み少ないけど非常に参考になります。

37 ：

稼働システムでDB設計がおかしくてPGで何とかしようとするのはいい
もう稼働してしまっているから大きな改造などは怖いので出来るだけやりたくないという理由
でも・・・なんであいつ等それを教訓にして次の土台の硬め方を変えようとしないのか
同じような設計して同じようなトラブル産んで・・・・
追伸
正規化とかもやりすぎは使いにくさにつながるかもしれないけど、適度な正規化くらいかけてください。

38 ：

今は昔よりサクサク作れるんでしょ？
ＤＢも使い捨ての時代じゃないの？

39 ：

アプリケーションはサクサクと使い捨てられることも多いけど、
DBは後々、受け継がれて残っていくからなぁ。
アプリケーションの進化に比べると、SQLやRDBの進化は遅いしね。
っていうか全角でＤＢ www

40 ：

遅いかねえ
最新のDBの機能なんて誰も使いこなしてねーじゃねーか

41 ：

昔IBMの博士がRDBの基礎理論を発表してから、常に進歩・進化していると思うが。
OracleやDB2なんかは使いこなしている奴の方が極レアだろうに。

42 ：

RDBMSの実装自体は猛烈な勢いで進化していますが、
スキーマ設計手法やクエリ言語に関しては案外ゆっくりと
しているのではないかと。
SQL92以降の拡張って実際どの程度使われていますか？

43 ：

LINQがどうなるのかってところか。＞クエリ拡張
あとは、ORマッピングの活用とかそっちも全然進んでなくね？＞特に日本

44 ：

xml関係の拡張(?)も凄いと思うし、モバイル対応とか、組み込みとか
あれこれ頑張っていると感じる。

45 ：

>>43
O/Rマッピングにそんなに価値を感じてるのですか？
流行に踊らされていませんか？

46 ：

そりゃまあ、COBOLerには縁がないから、価値を感じないだろうなぁ。

47 ：

COBOLは全然分からないが、DB設計の立場で見ると、
O/Rマッパには、
DB「設計」不要の簡易システムなら画面プログラマだけで作れる、
という以上の価値は感じられない。

48 ：

ポトペタな画面アプリ作る時には実際、O/Rマッパって必須だと思うけど。
簡単なものが簡単に作れるのは実際ありがたいし。
ちなみにDB設計不要ってくだりはｲﾐﾌﾒｲだな。
そりゃＤＢ設計者と思い込んでいる運用チームの人間が言っているなら
なんとなくわかるが。ｗ

49 ：

不要ってことは無いけど、重要視されてないのは事実。
糞なテーブル設計でも、一応動くし、速度も糞高い鯖でも買えば力技で何とかなるのも事実。
PGの学習能力は、そもそも糞なPGなのか、予算的問題で優秀なPGが確保できてないのか、営業的問題で長期運用を前提として無いとかだろう。
営業的には４年程度なんとか動いて、定期的に新しいシステムに更新してもらうのが儲かる。データ移行という名目でぼろ儲けしているのをわざわざ無くす必要は無いし。
運用ならもうちょっと強くってもいいと思うぞ。開発の尻拭いも大変だろうし。
そのままリリースしてしまうと業務に支障がでる！
と強くってやれ。実際、業務に支障が出るのは毎度の事だし。
ある程度汎用的に使おうとすると、結局は最新機能は使わずに終わってしまう事が多い。
このアプリケーションでは対応して無いとかで最大公約数的に使える機能が絞られて行く。

50 ：

むしろテーブル設計よりも、糞クエリを書く奴をなんとかして欲しい
SELECT一文で数KBとか馬鹿もいいとこ
このマシン遅いとか、冗談きついわ
アプリで処理すべきことをDBにやらせて遅くしてるのはお前だ

51 ：

俺の経験だとSQLで出来ることを
アプリにやらせて遅くしてるやつの方が多い。
とても遅くなって困る。

52 ：

http://capsctrl.que.jp/kdmsnr/wiki/bliki/?DomainLogicAndSQL

53 ：

>>52
なつかしいなそれ。割引金額をアプリで持ってるから
割引率変更になった時点で過去売り上げの改ざんになるのな。
揚げ足取りはさておき、ドメインロジックはまだいいんだけど
クロス集計とか頑張ってやってたのを見てびっくりした事ありますよ。

54 ：

クロス集計って、アプリ側、DB側、どちらで頑張っていたのでしょうか？
今はSQL/OLAPが使えるようになってきて随分楽ですね。

55 ：

>>51
テーブル設計がよろしくなくて、アプリ側でエラい苦労させられたことがある。
SQL書けねえやつに設計させるなと。

56 ：

テーブル設計が問題なのか、
SQLが問題なのか、
アプリが問題なのか…についてですが、
結論からいって、全てにおいてまずテーブル設計の問題だと思います。
理由はそれが土台だからです。
テーブル設計がおかしいという理由で、
おかしなSQLを書かざるを得ない状況に陥ることは多々あるし、
テーブル設計がおかしいから、
アプリでおかしな制御をせざるを得なくなったりするんです。
それと、「正規化もやりすぎると使いづらくなる」などという意見がありましたが、
自分は何があっても、どんなシステムあっても、どんな利用用途であっても
RDBでデータを管理する以上、必ず全てを第三正規形まで落とす必要があると思います。
正しくはその正規系を業務や仕様にあわせて（敢えて）「崩す」のです。
だから「正規化はしないほうがいい場合もある」というのは語弊があります。
正しくは「正規化は必ずしなければならない。その上で（状況に応じて）崩すことは構わない」
ということです。

57 ：

モバオクみたいに１人のスーパーエンジニアに全部ヤらせればいいんだよ。
要件定義から設計〜実装〜テストまで自前でやればドコがおかしいか
自分で気がつくだろうに。
時々、老害が自分の立場を守るためにくだらねぇ自己主張
しまくるから、設計がグダグダになっていくケースがあるしなぁ。

58 ：

一人はそいつが飛んだら終わりだけどな。
二人一組ぐらいにはするべき。

59 ：

さらっと「飛んだら」と書かれてちょっとビクっとした。
「意識が途切れる」「遠いところに逃げる」「宙を舞う」。含意は色々ですが。

60 ：

「レコード数が少ないから主キーはいらない」
と真顔でのたまう、うちのSE。。。

61 ：

>>59
飛ぶっていうのは逃げるとか逃亡するとか辞めるとかの意味。

62 ：

まず、Tか島平団地で飛ぶとか、そっちを考えたわｗ

63 ：

全てのテーブルが外部結合を必要なく設計されてるシステムってある？
あるコードに対して対象か対象じゃないかをマスタのレコードが有るか無いか
で判定するのはRDBとしては誤っていると思うんだけど。
RDB設計をまともにやればシステムの便利さは格段に向上するのは間違いない
システムへの要求も高度化するだろう。RDB設計をまともにしない人には
低度な要求を解決する仕事を続けるためにRDB設計を軽視し続ける
べきだ、保身のために。
日本は現場の国だ。現場以外は糞。そしてシステムに関する決定権は
現場には無い。使う側の現場力と開発する側の現場力が糞によって
互いに相反する方向へ注力させられている。まったく無駄なことよ。

64 ：

http://www.google.co.jp/search?q=result+site%3Acerema.co.jp
設計を軽視するとこうなる

65 ：

>全てのテーブルが外部結合を必要なく設計されてるシステムってある？
>あるコードに対して対象か対象じゃないかをマスタのレコードが有るか無いか
>で判定するのはRDBとしては誤っていると思うんだけど。
RDBでないDBはそうするしかないと思うが。
RDBでそうしているオマエの現場が糞と言うなら「そうだろうな」としかいい様がないわけだが。
「システムに関する決定権は現場には無い」ってオマエがオペレーターみたいな
現場といっても最底辺だとないだろうとは思うが、普通の開発現場なら
あからさまにイカれている設計なんかはレビューや評価で却下すればいいんじゃねーか？

66 ：

>>65
そのレビューとやらに呼ばれないｗ

67 ：

Oracleで対象非対象をレコードが有るか無いかで設計してあるのはやっぱ間違いだよね。
Oracleやってる奴も汎用機COBOLで経験つんだエンジニアばっか。COBOL流のシステム
設計をむりやりOracleに載せてる。それが常識で考えた標準らしいですよ。何も言えねえ。

68 ：

>対象非対象をレコードが有るか無いかで設計してある
こいつはどういう状態のことだ？
つうか、>67はどんな対案が正論だと言いたいんだ？

69 ：

ジョインされる２つのテーブルのキーが1:nになっているべきか1,0:nを前提に設計するかって話だよ

70 ：

んーっと
1:n設計は間違いだっていう主張？

71 ：

>>64
ひどいｗ
これは損害請求レベルじゃないのか

72 ：

ちがう、1:nを守るためにマスタにレコード追加しようとしたら引かれたの。意味無いとか言われて。

73 ：

レコード番号 | 存在フラグ
---------------------------
1　　　　　　　　| 存在する
2　　　　　　　　| 存在しない
3　　　　　　　　| 存在する
or
レコード番号 | 存在フラグ
---------------------------
1　　　　　　　　| 存在する
3　　　　　　　　| 存在する
の違いって事？

74 ：

あー頭死んでた。
レコード番号 | 対象フラグ
---------------------------
1　　　　　　　　| 対象
2　　　　　　　　| 非対象
3　　　　　　　　| 対象
※フラグ見て対象かどうか判断
or
レコード番号
-----------
1　　　　　　　　
3　　　　　　　　
※レコードの存在の有無で対象かどうか判断
の違いって事？

75 ：

>>72
どういう状況でどんなテーブルに何をしようとしたのか端的に説明してくれ。
とにかく状況が小出しじゃ何も判断できん。

76 ：

>>72
あと、「引く」という言葉の意味が分かりません。

77 ：

はぁ？
ひくわ

78 ：

>>63
なにか、ＲＤＢがあるからデータ入れよう的な考え方に聞こえるぞ
まったく結合するものがないなら、「Ｒ」ＤＢである必要はないわな
レコードがあるかないかで判断するか、（結合された）レコードに書かれてる内容で判断するかは、
それがどういった情報を格納してるかで決定するべきで、ＲＤＢなのだから
必要ない結合先のレコード（や、もしかするとそのテーブルそのものも）を作らないといけないということはないだろう
>そしてシステムに関する決定権は現場には無い
現場は必要もないＲＤＢを使いたくなく使ってるのかもしれないな
そして必要もないのに、ＲＤＢだからどうのこうのという、
現場の空気を読まない原理主義者みたいなやつがさらに話をややこしくするんだ
>>67
口調が違うが同一人物じゃないのか？
ちなみに、ＲＤＢ使った開発でＳＱＬを書いてるやつでも、
exists使ったことないってやつは結構いるだろう
ＲＤＢだから、ＯＲＡＣＬＥだから、レコードのあるなしで判断するのは間違ってるだろうとか
その判断基準がおかしいとしか思えん
まあ、現実的なＤＢの選択としてはＲＤＢＭＳしかない現状もあるがな

79 ：

１さんの言うことはまったくもって正しいんだけど、
実際にこういうことを口に出しちゃうと
「頭でっかちで現場じゃ使えない」って評価になるんだよね
おれがそうだからよく分かるwww

80 ：

制約を強くするとデータを入れにくいじゃない？とか平気で言うPLがいるとやる気0だよね〜
それで親の無い子レコードや、不正なデータが山のようにあるんじゃ世話ねーよ

81 ：

そうそう、そんな感じｗｗ
設計と製造の現場はまさに自分はDB設計を軽視してませんって顔して
キーマンの顔色を伺って程度をあわせる世界だよね。アホすぎｗｗ
ここもそんなもんだね。あ〜あ

82 ：

>>81
ここもそんなもんだねとか達観した気になる前にここで吐き出せよ。>80みたいに。
それすらできないくせに嘆くな。

83 ：

お前何言ってんの？

84 ：

俺？俺は何も言ってないよ。

85 ：

オレも何も言ってない。
>>86はどう？

86 ：

俺も。

87 ：

39+3 ： すずめちゃん(catv?) [] ：2009/01/20(火) 00:55:46.00 ID:5lC2DwfT (2/2)
市況２のスレを読んだら、どうも
データベースがぶっこわれたみたいで、金曜の取引データが飛んだみたい
で、約定メールから復旧させようとしてるとか

88 ：

取引先の「偉い上司」デター！
ぼくの考えたデータベース持ってキター！
さて、どうすっかな・・・

89 ：

データベース設計が軽視されているのではなく、
データベース設計に携わる人間が軽視されているのだ。
という命題をたててみる。

90 ：

>>89
それは、その人間の行う作業が軽視されてるから、
その人間が軽視されてるじゃないか
そうでないなら、別の人間が代わりにその作業をすることになるだろう

91 ：

そもそもちゃんと仕事できてないから人間的に信頼されて無いとか？
データベース以前の問題だな。
結局、現場の意見のほうが採用されて、ボンクラDBA涙目。
組織で仕事するという条件で目標を達成するためのスキームをちゃんと考えたほうがいいよ。

92 ：

ここ読んでて恐ろしいのは自分の関わったシステムではDB設計軽視して無いって
本気で思ってそうな人がいることだ。RDB的な不備が出るのは現実的に
仕方の無いことだが、あくまでも例外であって、あるシステムの中で数個の
数少ない心残りとして記憶されてしかるべきもの。
こんなバカだらけではキーマンの顔色を伺ってISAMバカ基準でシステムを組んだほうが
計画は立てやすいだろう。RDBMSを使ったPK、ソート、VSAMユーティリティと考える。
だいたいRDBMSをPK、ソート、VSAMユーティリティとしてシステム組んだ経験がある
人だとそれで正解だと誤解しちゃうんだろうな。それで動くから。
底辺会社の底辺システムの目標としてはそれでもいいだろう。動けば底辺客も
文句言わないから。しかし、そんな設計してRDBの特徴を活かさなかったら
RBD以前の非生産性を引きずったシステムが出来上がるわけだよ。しかし、
その非生産性は1円入札して保守で儲けるビジネスモデルでは工数が稼げる
かもしれんよ。いつか関わりたいなRDBのシステム。。。
そういえば某メガバン統合でCOBOLアホシステムで統合決定してるのが象徴的だねえ。
COBOLアホシステム準拠が日本では巻かれるべき長いものと決定したようなもんだ。

93 ：

メガバンのＭ菱サイドの方がオープン系とかにシフトする勇気がないんだろうし。
ああいうのは変に金があるから、コスト度外視の設計しても疑問に思わずに、
「こういうもんだ」と納得してんだろう。

94 ：

Mでは実績が無いだけでしょ。いわゆる前例がないってやつだ。
提案してるベンダもリスク回避として、今のシステム踏襲路線てのも悪く無い決断だと思うけどな。
まずは確実に統合して不具合を出さない事が第一目標だろう。一気に欲張って失敗するくらいなら、落ち着いてじっくり今後を考えればいい。
RDB的に正しい正規化した設計と、現場が把握し易い伝票ベースの設計のどちらがいいかは力関係も大きいし。

95 ：

>>92
お前の考え方は、道具に合わせてものを作れって考え方だ。
それはそれで否定しないが、その考え方だけが唯一の正解のごとく、
他の考え方を貶めるのはやめたほうがいいぞ

96 ：

DBAが満足する、実績の無い新しいシステムで、銀行ATM止めて大迷惑かけてしまうのと、
DBAは不満だけど、実績のある既存のシステムで、銀行ATM止めずに問題なく使えるのと、
どちらを決断するって話だろ。
DBA様の首斬って損害賠償請求ってもよければ、勝負もあり。

97 ：

しかしあのメガバンってアフォみたいにATMを停止させてる現実があるんだが。
単に突然使えないのが事前に「メンテナンス」と言う言葉で停止させるかの
違いなんだろうけど、その「メンテナンス」が予定時間オーバーも珍しくないワケで、
利用者としては「アレ？朝には使えるって言っていたのに･･･」ってクレームも
たくさんあるんだが。
結果論からすると「COBOLでも十分に失敗する」と言う前例は今回の合併だけでなく
以前から繰り返されている予定調和な感があるけどな。
U○Jの以前の倒壊＆惨羽の合併ではそんなに混乱は起きていないけど、
ＭとU○Jではこんなにゴタゴタしているのは、両者の技術レベルのギャップが
凄いんだろうなぁ。Ｍは特に悪評高いパッケージだし。

98 ：

それでもまだ復旧の見込みがあるぶんだけ優位だろ。
DBAの提案聞いてオープソ系とか導入して何日も復旧できなかったら終わる。

99 ：

あれくらいの仕事する案件では「失敗した時の復旧プラン」もちゃんと計画に入っているんだがな･･･。
「○時時点でこのチェックポイントをクリアできない場合は戻す」と言う具合に。
そこまでしておいて、それでも予定時間オーバーってのは、
COBOLを前提とするシステムと言うのは性善説に成り立っている仕組みが多いという事だな。
逆にオープン系なんかは性悪説(?)に成り立っている感があるので、
JOBの再投入もやりやすいように設計する人おおいからなぁ。
そして何日も復旧できない事態なんて存在しない。
オープン系が優位とは言わんが、COBOLが実績があって安定性云々なんて
寝言を言う人間は間違いなく現場の金融系の実体を知らん厨房だと思う。

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 削除依頼 ▲
・　次のスレ
ADO.NETの質問・雑談スレ2
【KVS】 Key-Value Storeを勉強するスレ
DB技術の限界を超える新発想の高速検索技術ISSEI
一番ボッタクリなDBってなに？