07/10/27 09:39:03
漏れも釣りだと思うが。
状況と関係が不鮮明なので、推測だけどとりあえずＣはどーでもいい仕事で、
「コレがわからないと先に進めない」なんて状況は現実的にないな。
そしてＢは「Ｃの説明する１分と言うのは大抵１分で終わらない」って
経験的に理解しているから「今それどころじゃねえ」と返答している可能性もあるのに
Aがしったか精神で「しかし、１分で済む・・・」なんて語られたら
現場の人間からするとウザい事この上ない。
Aが真にプロならＢの代わりにAがＣの質問に答えてやればいいじゃん。
それがお互いの時間を一番効率的に利用できるんだし。
509:仕様書無しさん
07/10/27 10:44:28
>>508
そうなんだよな。
質問に答えず説教することで余計なやりとりが発生して時間を無駄にするより、
質問の要点に答えて終わらせる方が時間の節約になる。
質問者がいつまでたっても学習しない奴なら説教は必要だろうが。
510:仕様書無しさん
07/10/27 13:19:37
ラスト訂正ってのがどうもな ｗ
511:仕様書無しさん
07/10/27 14:20:27
コボラーって、正規化できないんだよな
コボラーの設計したテーブルだと
SQLでアクセスしにくいんだよね
512:仕様書無しさん
07/10/27 14:46:53
このスレの主題が久々に出たな。
ついでにチューニングも利かん。
513:仕様書無しさん
07/10/27 16:32:53
コボラーの設計したテーブル その１
得意先別月別実績ファイル（コボラーは、テーブルのことをファイルと呼ぶ）
得意先コード、年度、１月実績、２月実績・・・１２月実績
（得意先コードと年度が主キー）
年度またがりで期間指定で集計しようと思ったら、
そのつどSQLを変更しなければならない
514:仕様書無しさん
07/10/27 18:10:36
>>513
俺の上司は、利率が変わったりといった
制度変更の履歴を横に持ってるぞ Riritsu12, Riritsu2, Riritsu3…
変わったら修正すれば良いでしょって、、、
コストは客に負担させるつもりらしい。
515:509
07/10/27 18:16:40
>>510
ははは。言われればその通り。
516:仕様書無しさん
07/10/27 19:04:46
SQL?なにそれ？
ブレイクさせろブレイク！
517:仕様書無しさん
07/10/27 19:20:09
横長のDBでしか設計できないのは、本物のコボラじゃない。
本物のコボラは木構造のＤＢ設計をするんだ。
RDBしか使った事ないおまえらには理解不能だろうがな。
518:仕様書無しさん
07/10/27 19:25:04
>>513
汎用系のファイルをそのままＤＢテーブルに置き換えてるだけだから
適用開始日１ 消費税率１ 適用開始日2 消費税率２
（５％になった時に後ろ２つを追加、関連ＰＧ改修したと思われる）
とかもある。この先税率が変ったら？
正規化の概念うんぬん、というより
「今正しく稼動してるものは変更しない」でガチガチと思われる。
519:仕様書無しさん
07/10/27 19:25:35
あー>>514見てなかった。ごめん。
520:仕様書無しさん
07/10/27 19:47:48
>>517
>>本物のコボラは木構造のＤＢ設計をするんだ。
お前ＲＤＢって何かしらないんだな ｗ
521:仕様書無しさん
07/10/27 19:48:33
わかってないのは>>520の方だけど
522:仕様書無しさん
07/10/27 19:53:03
>>520
Wikipediaで調べろ。
523:仕様書無しさん
07/10/27 20:14:51
>>520
木構造DBを直接使った事ないのは普通だと思うけど、知らないのはまずいぞ。
RDBも、インデックスは木構造DBだから、意識せずに使ってるてだけだからな。
インデックスに対してSQLのORやNOTが効かない理由を考えたことすらないのか？
勉強をしようともしない態度はおまいが嫌ってるコボラーといっしょだぞ？？
524:仕様書無しさん
07/10/27 20:23:14
>>520
知ったかぶりをすると勉強になる件。
みんなが教えてくれるからな。
でも、そんな親切な連中はあんましいないぜ。
525:仕様書無しさん
07/10/27 20:28:11
>>520
URLﾘﾝｸ(www.atmarkit.co.jp)
これ読んで勉強汁。
526:仕様書無しさん
07/10/27 20:54:17
>>514, >>518
うぉーっ
その２を先に言われてしまった。。。。
コボラーは、どこに行ってもコボラーってことか
527:仕様書無しさん
07/10/27 20:56:59
すまん、520はこれの事いってると思うのだ
URLﾘﾝｸ(ja.wikipedia.org)
528:仕様書無しさん
07/10/27 21:02:13
>>520は単に小鯔を馬鹿にしたかったんでは
529:仕様書無しさん
07/10/27 21:10:22
こうやって、いろいろ話が広がって
知識を習得する機会がうまれる。
520はいい仕事をした。
530:仕様書無しさん
07/10/27 21:11:03
＞「今正しく稼動してるものは変更しない」
という明確な意思なら勝手だけど、正規化自体まーったく知らない金融名古屋人とかいるよ。
531:仕様書無しさん
07/10/27 21:16:16
>>530
そこは注意が必要なとこで、
横長で初期開発が済んでしまったものはもちろんそうである。
これから汎用機からOPEN系へのリプレスをする段階では、
「今正しく稼動してるもの」とは言えない。
新システムはまだ稼動してないのだから。
532:仕様書無しさん
07/10/27 21:22:46
>>531
ユーフィットのアホにそのまま言ってやって
533:仕様書無しさん
07/10/27 21:28:42
ＣＯＢＯＬソースはそのまま移行（データ扱い部分をＳＱＬに自動変換）するから、
現汎用システムのレイアウトのまま、ＤＢテーブルで定義したりするね。
534:仕様書無しさん
07/10/27 21:37:08
正規化させろ
535:仕様書無しさん
07/10/27 21:43:30
コボラーのプログラム設計
売上実績ファイルと得意先マスターから得意先別の集計表を作成
だいたい、こんな感じ
1.得意先マスター取得ループ
1.1.売上実績ファイル取得ループ
（１で取得した得意先コードを指定）
1.1.1.売上実績の計を求める
1.2.売上実績がゼロ以外のとき、得意先マスタの情報と売上実績の計を出力
Group By使えよ
売上実績と得意先マスターを結合しろよ
SQL一発でできるぞ
536:仕様書無しさん
07/10/27 21:45:40
石頭金融はselectも * しかできないと思ってますよ。
537:仕様書無しさん
07/10/27 23:22:08
>>531
とか言ってたベンダが仕様温めやがって、結局納期ギリでコボルそのままになった経験
538:仕様書無しさん
07/10/28 02:14:13
>>531
汎用機からオープン系へのリプレースで横長にされました。
プログラムの中身も、データ部分とUI切り分けるでもなく
1つのクラスの中に長々と全部・・・
>>535
いいえ、真のコボラは大して重くない集計票でも、
月次処理などで集計済テーブルを別に作ろうとします。
○○集計テーブル、××集計テーブルと…帳票用のテーブルが山のように作られます。
539:仕様書無しさん
07/10/28 03:37:58
>>538
そうそう、集計済みテーブル好きだよね。
ちょいとしたSQLで1秒かからずに出るのに、ストアドプロシージャで
データ追加のたびに集計表更新してる。
しかもプロシージャとかそれを呼び出すプログラムが腐ってて
集計結果間違えたりしてんのｗｗｗ
540:仕様書無しさん
07/10/28 06:40:13
>>532
＞ユーフィットのアホにそのまま言ってやって
そおいや、その会社のCOBOLソースを見たら
正規化って概念知らずにソース内で力ワザをしているのを
何回か気が遠くなったな。
しかもそういう劣悪設計なのから「修正新規」とかで
劣化コピーなプログラムが何本かあって、不具合や仕様変更が発生すると
お約束で原本＆劣化軍団を同時に修正しなきゃいけないから、
修正コストやユニットテスト、連動テストのコストがバカにならん・・・。
その場しのぎの短絡的思考なヤツが多いと思う。金融系＆COBOLerは特に。
541:仕様書無しさん
07/10/28 08:20:00
>>538,>>539
そそ、集計テーブル好きだね
入力処理の実行時に集計テーブルへの更新もやったり
”日次締処理”で日次の集計処理をやったり・・・
＞集計結果間違えたりしてんのｗｗｗ
そこで、再集計処理ですよ。
542:仕様書無しさん
07/10/28 10:58:32
というか、プログラムで処理すりゃいいようなレベルをなぜか
DB上で実行しようとする(多分ファイルメモリの記憶が濃厚なんだろうけど)
・・・今更256もつんでりゃ一万位のデータ問題なく処理できるって。
543:仕様書無しさん
07/10/28 11:35:19
逆にDBにまかせりゃ良い事をプログラムでやろうとしたりな。
544:仕様書無しさん
07/10/28 12:00:38
コボラーはストアドになんか変な幻想抱いている気がするね。
ストアドで実質プログラム書いた事あるよ・・・。
別ストアドを関数として、
XMLDBを変数領域として、
えらく遅かったです。
545:仕様書無しさん
07/10/28 12:01:00
VBとDEVELOPERが共存するシステムで
CSV取り込みをDEVELOPERで
ストアドCALLするだけの画面をVBでやれ
といわれたときゲンナリした。
546:仕様書無しさん
07/10/28 12:08:23
>>540
それは現在の俺の状況に近いものがあるな・・・死にたいです・・・
547:仕様書無しさん
07/10/28 12:59:59
>>545
VBでなくPBで経験した。
548:仕様書無しさん
07/10/28 13:48:35
3回集計して、結果が同じだったらOKって事で。。
549:仕様書無しさん
07/10/28 15:38:08
>>548
2回目と３回目の間に、他の人が別のＰＣでデータ登録して
２回目と3回目の集計結果が違った
って、落ちはないの？
550:仕様書無しさん
07/10/28 17:15:31
でもSQLで出来るからってA4 4～5枚のSQLかれた時はまいったよ。
オープン系の若い兄ちゃんだけどね。
コボラーの簡単SQL+プログラムもまいるが.....
バランスって難しいねぇ
551:仕様書無しさん
07/10/28 19:14:00
その辺のバランスを、うまく取るのがセンスかな
頭の固いコボラーには、無理だろうな
552:仕様書無しさん
07/10/28 20:55:48
一番困るのがその頭の固さ。
知らないことは詳しい人に聞いて最善の方法を考えようとか絶対しない。
メールの「グループ化」すら知らないのか嫌なのか、
３０人くらいのアドレスを書き連ねて送信。
当然忘れられる人もいる。
うるさいけどできる外注のおばさんをそれで怒らせて辞められてしまった。
553:仕様書無しさん
07/10/28 22:46:46
最近、コボラーを雇ってる金融機関にとても不安を感じる今日この頃
日本の将来は大丈夫か
ＯＬＤコボラってプルグラムを組ませていけないのかなぁ
３０年前から進歩がないやつらみたいだし
windows使えこなせそうだし
554:仕様書無しさん
07/10/28 22:54:37
日本語でおｋ
555:仕様書無しさん
07/10/28 23:20:13
553は金融機関とかで働きたいニートなのか？
556:仕様書無しさん
07/10/29 02:04:52
団塊の新作はまだかなぁ。
作家は何人いるんだろう？
557:仕様書無しさん
07/10/29 02:06:27
次回からサブタイトル付だとおもしろいな。
558:仕様書無しさん
07/10/29 02:11:07
汎用使うような業種はそもそもお硬く役所的で根拠ないプライド高いから、
変化や協力、効率性とか排除しがちなんだろうな。
559:仕様書無しさん
07/10/29 06:48:34
働く人間の全員がそういうワケではないが、そういう風に職場的に洗脳している
雰囲気はあるな。
つか、COBOLを保守メンテする案件ってぶっちゃけ無能でも出来るから、
って理由がほとんどだと思うが。
最初のシステム構築はどんな言語であれ出来る人間がいないと辛いけどサ。
560:仕様書無しさん
07/10/29 06:52:31
SE（いちおう技術者としとく）になりたいというより、
○○銀行、証券、生命の系列会社に入りたかった人間が多いから。
一番直前名前挙がってる会社なんて
人生に「ひがしうみ ぎんこう」の名前が欲しくて、
実家を離れたくなくて入った人ばかりだから。
561:仕様書無しさん
07/10/29 16:30:12
コボラーはこんなのがすき
ｽﾚﾘﾝｸ(db板:191番)
562:仕様書無しさん
07/10/29 23:15:23
次スレ候補
【非正規化】コボラは横長DBがお好き ３カラム目【用済み】
563:仕様書無しさん
07/10/30 00:08:57
Ｂ『Ｃさんをどう思いますか？』
Ａ『Ｃどうって？何の話ですか？』
Ｂ『仕事の面で....』
Ａ『まぁ、普通なんじゃないでしょうか？
彼は大学出て就職してまだ１年半くらいと聞きましたが。
何か、問題でも？』
Ｂ『いえ、ちょっと要領が悪いというか、
他の人と比べるとちょっと割りに合わないというか....
出している金額は多少安いんですが....』
Ａ『そうですか。彼も私と同じように３ヶ月契約ですかね？どうされるんですか？』
Ｂ『次回はお断りしようかと思ってるんですが....』
Ａ『そうですか。しかし、「切る」というのは簡単ですが、
それによるマイナスも十分に考えておいたほうがよいかも知れませんよ。』
Ｂ『いや、Ｃさんが抜けても特に....』
Ａ『いえ、そういうことではありません。
たとえば、Ｃさんが１０年目ならまぁ、切るのも仕方のないことでしょう。
しかし、１年半となると事情が違ってきます。』
Ｂ『といいますと？』
Ａ『１年半となると今のような現状は容易に想像がつきますね？
完成品が欲しければＣさんは初めから受け入れないというのが常識的な判断です。
使えない人員を出す方も問題ですが、
受け入れるということはそれを了承していると思われても仕方ありません。
１年半ですからね。
これは、派遣元の業者はもちろんのこと、自社の上司や同僚からも
Ｂさんの評価が下がる要因になるでしょう。』
Ｂ『上司はまだしも、派遣元の業者が評価ですか？』
Ａ『評価というのは語弊があるかもしれませんが、
「非常識な客だ」とか「だから安いんだろ？」と思われるということです。
思う方も思う方ですが、一旦受け入れてしまっていますからね。
外注業者への心証は意外と侮れないものですよ。』
564:仕様書無しさん
07/10/30 00:46:18
Ａ『Ｃさんとこは誰のツテでしたっけ？』
Ｂ『部長のツテですが....』
Ａ『Ｃさん一人についてのことで問題になることはないと思いますが、
「切ればいい」と思っていては、人を出してくれなくなることがありますからね。
当然、部長もいい気はしないどころか、部長の受け持っている他プロジェクトにも影響しかねません。』
Ｂ『....確かに。』
Ａ『これらは目に見える範疇で、本当に恐ろしいのは
Ｂさんが「切る人」であると思われてしまうことです。
こうなると、周りの人間がＢさんを怖がるようになります。
そして、Ｂさんの意見に反対する人が減るでしょう。
なぜなら、切られたくないからです。
これは、外注のみならず、自社の後輩や同僚についても同じことです。
こうして、誤った意思決定が横行してしまうわけですな。
リーダーは決して嫌われてはいけないんです。』
565:仕様書無しさん
07/10/30 00:48:32
>>563,564は間違いなくコボラ
566:仕様書無しさん
07/10/30 00:49:48
1週間で切られるような環境で育ってきたから
馬鹿らしいことこの上ない。
567:仕様書無しさん
07/10/30 01:02:39
Ａ『「デスマーチになった結果、嫌われたリーダ」というのはレアで実際は
「リーダが嫌われた結果、デスマーチになった」というケースほとんどです。
「和気藹々とデスマーチ」なんてのもごく少数ですが、あるにはありましたが....これはどうでもいいですね。』
Ｂ『そうなんですか。プロジェクト管理より嫌われないことですか。』
Ａ『そうです。というか、人心掌握力を欠いてはプロジェクト管理などありえません。
小規模ではどうにでもなりますが、１００名規模などとなるとリーダの人柄が命運を分けるといっても過言ではありません。
将来的にはその規模を任されたいと思っているのですよね？』
Ｂ『....はい。』
Ａ『それなら、「切る怖い人」ではなくて「育てる優しい人」を目指した方がよいと思います。外注も育ててナンボですから。』
Ｂ『そうですね....Ｃさんは長い目で見ることにします。』
568:仕様書無しさん
07/10/30 01:13:25
お、新作。
以前、デスマーチの挙句、外注が手を引いて別の外注業者に
ＰＧ一人１００万／月 取られてたバカがいた。
569:仕様書無しさん
07/10/30 01:34:28
外注を育てる？
金払って育てるんか？
570:仕様書無しさん
07/10/30 01:36:54
>>567
こうやって（優しさを勘違いした無能な）リーダーが作られていくのか・・・・・・
571:仕様書無しさん
07/10/30 01:40:09
まぁ、１００名規模のリーダにスキルなど....
572:仕様書無しさん
07/10/30 01:50:47
お前らクチだけは達者だなｗ
573:仕様書無しさん
07/10/30 01:50:57
第一話
>>300-301
第二話
>>360-361
第三話
>>372
第四話
>>463-466-467
第四話
>>474-476
第五話
>>482
第六話
>>501
第七話
>>563-564-567
第一話、第五話は秀逸。
あとは駄作。
574:仕様書無しさん
07/10/30 01:53:54
四話が２こありますが？
575:仕様書無しさん
07/10/30 01:55:16
失礼！
第一話
>>300-301
第二話
>>360-361
第三話
>>372
第四話
>>463-467
第五話
>>474-476
第六話
>>482
第七話
>>501
第八話
>>563-567
第一話、第六話は秀逸。
あとは駄作。
576:仕様書無しさん
07/10/30 02:22:54
すべて駄作。
577:仕様書無しさん
07/10/30 07:37:25
>567
おかしな話でAもＢもＣもプロジェクトのリーダーには慣れないと思うんだが。
リーダーと呼ばれる人間は、ワリと本人が意識しないウチにリーダーにならされていた（w)
ってケースも多いぞ。
正直、目の前のくだらねぇ問題で喚くレベルの人間がリーダーになるのは不可能に近いぞ。
578:仕様書無しさん
07/10/30 10:19:39
切りたくても、切らねぇ！って
カイジかよ。
しかもついこないだアニメで放送した分。
579:仕様書無しさん
07/10/30 19:43:17
嫌われるとか好かれるとかをいちいち考えている人はプロマネに向いてない。
小チームのリーダーぐらいならともかく。
580:仕様書無しさん
07/10/30 20:25:45
>>563-579
マごときが、プロジェクト管理語るか。
581:仕様書無しさん
07/10/30 23:10:24
一応管理者ですが、何も。
582:仕様書無しさん
07/10/30 23:19:46
係長も大変だな。
583:仕様書無しさん
07/10/31 00:21:35
>>567
無能だから嫌われた上でデスマになるってだけじゃないのん。
デスマになってから無能に気づくか、無能で嫌われたままデスマに突入するのか。
無能が原因でデスマしてたら和気藹々にはならなんだろうし。
584:仕様書無しさん
07/10/31 00:34:38
>>567
すごい反響だな。
585:仕様書無しさん
07/10/31 00:49:42
コボラの屁理屈に、飽きてきた
笑えるのがいいんだけど
586:仕様書無しさん
07/10/31 00:50:52
無能が無能を斬る。
それが２ｃｈ。
587:仕様書無しさん
07/10/31 01:24:43
しかし上手く斬れず別の無能が絡む
それが2ch
588:仕様書無しさん
07/10/31 01:44:14
>>585
熱心なファンだな。
589:仕様書無しさん
07/10/31 03:34:30
>>567
明日、会社の女子トイレでオナニーをしろよ。
590:仕様書無しさん
07/10/31 13:57:40
えらく伸びててハァ？と思ったが・・・
外注を育てるのはアホくさいが、外注にしても自社社員にしても
育つ場は現場だからなぁ。
どの現場でも切ることしかしないなら、無能な外注が増えて
デスマに陥る率も増えるだろ。
しかし爺の言うことは正論でも、育てる立場の会社や人間からしたら
ババを引いているにも違いはない。
591:仕様書無しさん
07/10/31 20:46:42
すごい！このスレってできる人ばっかしなんですね。
592:仕様書無しさん
07/10/31 22:24:58
八話が最優秀ってことでＦＡ？
593:仕様書無しさん
07/11/02 00:34:23
誰か、『氷河期ＶＢ厨』書けよ。
594:仕様書無しさん
07/11/02 00:39:03
１）COBOLER（コボラ、コボラー）
業務知識が豊富である反面、言語知識は最低限である場合が多い。
上流工程向け。今となっては希少な存在。
年収は３００万～１２００万程度。
２）オープン系技術者（ソルジャー）
仕事と趣味を混在させることが多く、更には自覚がない。
代わりはいくらでもいると思いきや、想像以上にハズレが多い。
仕様書に書いてあるより「上（設計）の事」には想像をめぐらすことが出来ないが、
仕様書より「下（手段）の事」にはこだわりがある。
年収は２５０万～４５０万（４０歳）程度。
595:仕様書無しさん
07/11/02 01:23:06
>>594
言語知識最低限じゃあどうせ設計もロクにできんだろうに…上流工程でも迷惑なだけだろ。
無駄に重ねた年齢故の立場、責任転嫁する権限があるから…切れないだけで。
というかそれぞれの区分の中で使える奴と使えない奴が混ざってるのにそこ分けないで持論に有利な点だけ抽出すんなって。
596:仕様書無しさん
07/11/02 01:51:05
重要なのはDB回りと通信なので、言語は誤差
スクリプト言語まで行くとさすがにまずいがな。
コーダにゃ、運用設計できないし。
597:仕様書無しさん
07/11/02 02:44:23
『ＸＸ回り』ってよく聞くけど、いつもイライラする。
598:仕様書無しさん
07/11/02 06:39:03
＞１）COBOLER（コボラ、コボラー）
＞
＞ 業務知識が豊富である反面、言語知識は最低限である場合が多い。
＞ 上流工程向け。今となっては希少な存在。
こいつらのクソ設計のおかげで中日が日本一の瞬間も障害対応していましたが、何か？
599:仕様書無しさん
07/11/02 20:24:56
>>596
ダウト。
言語によって得手不得手の設計が有る。これは決して誤差レベルではない。
コーダの話は誰もしてない。オープン系＝コーダとか思うのならいっぺん死んで来い。
っつかスレタイ嫁
600:仕様書無しさん
07/11/02 21:00:56
「ＤＢ周りと通信」
「ＤＢと通信」
601:仕様書無しさん
07/11/02 21:46:52
ユニークIDに意味をもたせるな！
602:仕様書無しさん
07/11/02 22:03:57
>>601
主キーと候補キーで使い分けるならアリなんだが。
603:仕様書無しさん
07/11/02 22:14:16
DATEよりNUMBER(8,0)かCHAR(8) がいいと思うのは俺だけ？
604:仕様書無しさん
07/11/02 22:27:46
>>603
なんで？既存システムとの兼ね合い？
605:仕様書無しさん
07/11/02 22:29:39
具体的に言うと名前を主キーにしないでください！
606:仕様書無しさん
07/11/02 22:58:12
年金システム？
607:仕様書無しさん
07/11/02 23:27:48
>>603
必ずや日付として無効なデータが入るであろう。
今年は10月が60日まであればよかったなー
608:仕様書無しさん
07/11/03 00:36:19
>>607
え？ごがつだよ？ねんはわすれたけど。
けんしゅうとかいうのがおわらないと６がつにならないっていってたんだ。
609:仕様書無しさん
07/11/03 01:01:23
>>607
それはあるんだけどな.....
しかし、インデックスが.....
610:仕様書無しさん
07/11/03 03:44:46
>>603
そうだね
DATE型だと、時間まで入ってしまうしね。
それに、未入力だとNulｌになってしまう。
Ｎｕｌｌは、あまり使いたくない。
オレも、よくNumberかCharで作成する。
611:仕様書無しさん
07/11/03 04:49:22
>>610
釣れますか？
612:仕様書無しさん
07/11/03 05:19:52
腐ってやがる...
遅すぎたんだ...
613:仕様書無しさん
07/11/03 07:04:13
>>609
格納したいものが、charで表せるようなもんで十分だと言うことが仕様上明確であれば、
別にcharでも良いと思う。
インデックスのためってのは、設計段階ではあまり理由にならない。
チューニング段階で、求められている速度に達しなくて、そこしかいじるところが無いって場合に初めてやればいい。
614:仕様書無しさん
07/11/03 07:39:27
>>610
Oracleが世界の中心みたいな発言でつな。
DB2はんな事ないんだが。
615:仕様書無しさん
07/11/03 10:25:06
まぁ、OracleとDB2とでは、技術者の数が違うからな
Nullって難しいよな
コボラーや年寄り技術者はもちろん、若いSEも理解していない奴が多い
DB製品間でも微妙に扱いが異なっているし
616:仕様書無しさん
07/11/03 13:37:40
>>613
チューニングってやったことありますか？
617:仕様書無しさん
07/11/03 13:45:53
>>615
Nullは値を持っていない…って解釈じゃマズイんかな？
自分とこの会社のコボラ連中、null不許可のvarcharだけでDB設計しやがった…orz
ワークテーブルも山ほど、ストアドの中はカーソルだらけ。
618:仕様書無しさん
07/11/03 14:47:56
正直な話、ＤＢのNULLの考え方はCOBOLerよりもまだ、Accessを使う
エンドユーザーの方が解っている気がしなくもない。
あとCOBOLerは「one fact in one place」の基本が出来てないヤツが圧倒的に
多いからアフォみたいにワークテーブル作るんだよな。
619:仕様書無しさん
07/11/03 15:40:29
多くのコボラーは
数値型でNull ＝ ゼロ
文字型でNull ＝ 空白
などと勘違いしている
コボラーなら、可変長のvarcharを使わず、
固定長のCharでNot Nullオンリー（笑）
620:仕様書無しさん
07/11/03 15:46:17
レスポンスが悪いからとテーブル設計を変えたり、
インデックスを追加したり、プログラムをSQLレベルではなく
ロジックそのものを変更したりするのは、
もはやチューニングではなく、
設計不良の修正
出来損ないのプログラムの修正
だろう
621:仕様書無しさん
07/11/03 16:52:53
>>619
いや、varchar使ういみ分かるならいいんだよ。
char 2～4でもvarcharにしたり、必ずmaxうまる項目にvarcharしたり
なんかdefみたいな?
まぁこんなこと言うとおっさんあつかいだけどね
622:仕様書無しさん
07/11/03 20:16:24
>業務知識が豊富である反面、言語知識は最低限である場合が多い。
これも付け加えておいてくれや。
つ【金の使い方が解らない】
623:仕様書無しさん
07/11/03 20:51:36
でも評価や金になるのは前者 "業務知識が豊富"
624:仕様書無しさん
07/11/03 21:07:28
業務知識って豊富なのかなぁ。
「保守経験が長い」ってのは納得だけど、
多くのCOBOLerって上流工程(この単語嫌い）から来た
仕様をそのままコードにして動かしていて、頭使わない日常送っている人が
ほとんどだと感じるけど。
625:仕様書無しさん
07/11/03 22:13:36
>仕様をそのままコードにして動かしていて、頭使わない日常送っている人が
>ほとんどだと感じるけど。
これについては、コボラーもゆとり世代も変わらないよ
626:仕様書無しさん
07/11/03 22:53:12
ゆとり世代の円周率はナンボだったけ？
627:仕様書無しさん
07/11/03 22:55:51
おおよそ3
628:仕様書無しさん
07/11/03 23:08:01
>>627
それは都市伝説で、キチンと小学校では3.14と教わっている。
中学ではそれがπに置き換わる。
629:ゆとり世代
07/11/03 23:11:45
ゆとり世代以前は複素数平面てなかったなんでしょ？
大半はベクトルって何か理解できてないんじゃないのかな？
630:仕様書無しさん
07/11/03 23:20:45
>>626
>>628
>>629
分かりやすくて恥ずかしくなる釣り。
631:仕様書無しさん
07/11/03 23:23:52
>>613
チューニングは設計ありき。
いくらインデックスを張ろうが、
『データがないこと』に勝るもんは何もない。
データを削除、あるいは退避する機能のないシステムはいずれ破綻をきたすことは自明。
632:仕様書無しさん
07/11/03 23:26:36
ていうか、事後にチューニングなんてバカのやること。
633:仕様書無しさん
07/11/03 23:27:31
ていうか、チューニングしなければならない状況がすでにバグ。
634:仕様書無しさん
07/11/03 23:29:22
>>631
つまり時々DB吹き飛ばせと。
635:仕様書無しさん
07/11/03 23:33:18
スラドは優秀だな
636:仕様書無しさん
07/11/03 23:51:53
事後になってチューニングを必要な設計をするのは***。
637:仕様書無しさん
07/11/04 00:14:43
>>624
スレチだが、上流行程と言うから嫌いなら前作業と脳内変換。
やっている奴らは前座に脳内変換。意外としっくりくる。
638:仕様書無しさん
07/11/04 04:01:52
>>636
繰り返しはいらんわ。
639:仕様書無しさん
07/11/04 04:09:11
偏差値７０～８０：人の使い方について考えてもいい人種
偏差値６０～７０：仕事のやりかたについて考えてもいい人種
偏差値５０～６０：最終的な成果物について考えてもいい人種
偏差値４０～５０：部品の組み立て方を考えてもいい人種
偏差値３０～４０：命令を理解すればいいだけの人種
偏差値 ～３０：脳内の活動を完全に停止しなければならない人種
640:仕様書無しさん
07/11/04 05:13:07
>>634 は、マジレスでは、ないと思うけど
>>631の言っていることは、正論だな
データの有効期限は、その会社の事業内容や、データの種類によって異なる
無駄に過去データを残していてもリソースの無駄遣い
レスポンスが悪化するのはあたりまえ
データの有効期限や、想定されるデータ量、要求されるレスポンスなど
要件定義や設計段階で設計段階で決めておくべき
641:仕様書無しさん
07/11/04 12:22:13
>>639
だから「回りは低能ばかり」と自分の偏差値をあげたがるわけだ
能力値 != 偏差値
642:仕様書無しさん
07/11/04 13:23:10
>>641
>>639 は大学のこといってんだと思うが。
「回りは低能ばかり」は低学歴がよく使う呪文。
643:仕様書無しさん
07/11/04 13:34:16
>>642
大学入試の偏差値の話？
644:仕様書無しさん
07/11/04 16:08:44
適性ってのが、意外に重要な気がする
単に勉強の量をこなすことで良い大学に入った奴は
システム開発に向いていないと思う
最小限の労力でどうすれば最大の結果を得ることが
出来るかを考えるのがシステム開発の本質だからね
645:仕様書無しさん
07/11/04 16:41:26
あまり勉強しないで二流大学に入った奴と、
ガリ勉して一流大学に入った奴では、
どちらが適性あるのだろうか？
646:仕様書無しさん
07/11/04 19:04:43
適正でなく、格。
低学歴は上に上がれないシステムになっている。
それでいい。
賢い低学歴を賢くない高学歴が使って搾取する。
それがＩＴ業界。
道義的によいかわるいかなど問題ではない。
647:仕様書無しさん
07/11/04 19:14:19
要は能力がるかどうか、頭がいいかどうかなどはどうでもよいこと。
賢い低学歴に「そんなこともわからないんですか？」と言われつつ、
定時で退散し、倍の給料をもらう。
だから、賢い底辺は丁重に扱うし、意見も積極的に聞くようにしている。
それで、自分の高収入が支えられてるんだなぁと思うと感謝せずにはいられない。
入り口間違わなくてよかったとしみじみ思う。
648:仕様書無しさん
07/11/04 19:36:39
コボラーとDBの話から学歴の話にズレてきている
みんな学歴の話になると必死だな
よほどコンプレックスがあるんだな
649:仕様書無しさん
07/11/04 19:49:25
いいポジションを得るためには、
世渡り上手＞＞＞＞学歴
650:仕様書無しさん
07/11/04 20:51:09
学歴厨って結局、世間知らないなあって感じしか受けないな
日本のIT業界の問題って、単に他の業界じゃとっくの昔に解決
されてる問題に過ぎないのに、なぜだか知らんが今自分の
おかれている状況こそ普遍的なことだみたいに思い込んでる
651:仕様書無しさん
07/11/04 20:55:57
>>650
>>学歴厨って結局、世間知らないなあって感じしか受けないな
それでいいんだって。
大切なのは手厚い待遇。
それを得るために能力を発揮しなければならない人間と
そうでない人間がいるというだけの話。
能力がなくても高待遇な人間は世間知らずでも全く問題なし。
貴族が俗世間を知らないのと同じだな。
652:仕様書無しさん
07/11/04 20:58:28
貧乏ほど、法律の半可通であるのはそういうことか。
653:仕様書無しさん
07/11/04 21:37:07
手厚い待遇は恒久的なものなのかな？
654:仕様書無しさん
07/11/05 00:30:03
政治力ってのは大事だわな
ただ社長が同じ大学という理由で外注選んだりするのは勘弁願いたい
655:仕様書無しさん
07/11/05 00:55:59
『外注を選ぶ』って固定的な外注先ないの？
そういうコネがあるのとないのとでは大違い。
656:仕様書無しさん
07/11/05 01:28:54
学生ベンチャーあがりの会社もバカに出来ないからねぇ。
657:仕様書無しさん
07/11/05 17:07:41
いや学生ベンチャーは異常系が甘いというか、
酷いのになると障害時の運用設計って概念無い人いるし。
「このタイミングでハード障害が起きた時はどうするの？」
「このタイミングで回線が切れたらどう動くの？」
とか突っ込むとポカーンとした顔で
「ハードが壊れたらどうにもなりません」
だって。
WEBのおもちゃみたいなCGIじゃないんだがな。
658:仕様書無しさん
07/11/05 17:13:38
>>657
でお前はどうするの？
659:仕様書無しさん
07/11/05 18:53:11
>>658
エラーハンドラぐらい書けって話じゃないの？
例えば二重化とか無しで、
ハード障害→エラー箇所のログ吐いて強制停止+管理者へ通報
回線障害→時間差掛けてリトライ、場合によっては回数カウントして一定量超えたら強制停止ないし管理者へ通報
みたいな。
しかし書き方が悪いな。
「ハードが壊れたらどうにもなりません」ってのは確かで、「管理者にメール送信して終了します」等が続くかどうかが問題なんだと思うけど。
「WEBのおもちゃみたいなCGI」って言い方もどうかと。おもちゃみたいなプログラムならCGIに限らないし、CGIを見下してるように見える。
「同時アクセスでカウントが吹っ飛ぶカウンタ」とか指してるとは思うけど…
660:仕様書無しさん
07/11/05 19:09:55
＞いや学生ベンチャーは異常系が甘いというか、
＞酷いのになると障害時の運用設計って概念無い人いるし。
学生、関係ないと思うぞ。
この間、汎用機からのメッセージが来なくて
永久にJOBが走らないトラブルがあって、
激しい障害が発生したんで、作ったSEに
「テメーの設計どうなってんだ！？」と問いただしたら
「ホストからメッセージがこない事なんてありえません」とヌカして
エラーハンドリングをまったく実装していないアフォがいたからな。
オープン系の方が異常系のハンドリングとかログとかしっかりやってる感があるな。
ウチの周りだけかもしれんが。
661:仕様書無しさん
07/11/05 19:23:36
学生もオープンも汎用機も関係なく、そういうのは一定割合で偏在している。
662:仕様書無しさん
07/11/05 19:33:59
「やだなぁ、メッセージが来ない場合があるんなら、ちゃんと仕様書にそう書いといてくださいよ。」
663:仕様書無しさん
07/11/05 20:25:23
学生ベンチャーあがりは外注だけでなく発注元にもなっていると思うが。
664:仕様書無しさん
07/11/05 20:36:22
>>661
なるほどな。
で>>657-663 の中にも確実にいる、と。
665:仕様書無しさん
07/11/05 23:14:41
結論、コボラは横長ＤＢがお好き
666:仕様書無しさん
07/11/05 23:23:47
『スレタイ』を『スレ題』と言ってたやつ見たことある。
667:仕様書無しさん
07/11/06 07:31:26
>>666
それ、馬鹿にするところなんだろうけど、ウマイ言い方だな。
668:仕様書無しさん
07/11/06 22:49:39
プログラム板に「COBOLは俺にきけ」なんてのがないのが不思議
くだらねぇ長文入力しているよりましなんじゃねぇ
669:仕様書無しさん
07/11/06 23:41:56
そりゃ、COBOLは読んで演算して書いての繰り返しだけだもの
入力データをどう加工すべきかは純粋に業務要件だけの話なんで、
技術知識の出番がないから「俺に聞け」みたいなスレは不要
670:仕様書無しさん
07/11/07 01:12:12
それじゃ、汎用機（ＪＣＬ）なら俺に聞けっていうのはどうだ
671:仕様書無しさん
07/11/07 02:06:14
シャア専用機なら俺に聞け。
672:仕様書無しさん
07/11/07 02:16:42
何色ですか？
673:仕様書無しさん
07/11/07 20:54:50
>>671
char専用機？
674:仕様書無しさん
07/11/07 21:10:56
そのうちvarchar専用機になるな
675:仕様書無しさん
07/11/07 22:24:15
ぬるぽ専用機？
676:仕様書無しさん
07/11/07 22:33:59
>>674
そして当然、varchar2専用機に乗り換える。
677:仕様書無しさん
07/11/08 23:40:45
そして、会社からの命令でNUMBER専用機に乗り換えさせられる
678:仕様書無しさん
07/11/09 00:31:01
ンなアホな
679:仕様書無しさん
07/11/09 09:51:12
桁数なんて飾りです。
偉い人にはそれがわからんのです。
680:仕様書無しさん
07/11/09 22:35:58
>>679
じゃ、お前は時給も日給も月給も一桁な
681:仕様書無しさん
07/11/09 22:40:07
>>680
1桁って事は桁数指定してんじゃん。だめだめ。
Oracleだと最大値いくつだったっけかなあ。
大金持ちだぜ。
682:仕様書無しさん
07/11/09 22:40:59
>>679
お前のバグでデスマを発生させたことあるだろ
683:仕様書無しさん
07/11/09 22:58:32
>>682
バカみたいに桁数指定にこだわりまくる
COBOLあがりのリーダーのせいで
桁あふれでコケたことはあるよ！
684:仕様書無しさん
07/11/09 23:05:52
>>680
2の64乗進数で一桁という事でどうでしょう？
685:仕様書無しさん
07/11/09 23:17:59
桁数と学歴の話は好きだなコボラ
686:仕様書無しさん
07/11/10 21:02:23
>>680
>>679 が何が言いたいかは "ジオング" でぐぐればわかる。
687:仕様書無しさん
07/11/10 21:03:35
>>682 もな
688:仕様書無しさん
07/11/10 21:23:57
>>686
デスマなんて飾りです。
偉い人にはそれがわからんのです。
こうですか？わかりません！＞＜
689:仕様書無しさん
07/11/10 22:03:50
そうかデスマが飾りか
そうやって残業代を稼いでいたんだな
コボラの生活の知恵を見た気がした
690:仕様書無しさん
07/11/10 22:34:54
"ジオング" ＋ "偉い人" でぐぐれば一発じゃまいか？
691:仕様書無しさん
07/11/10 22:48:30
「コボラが居ればデスマと最適化で稼げる。かかってこいやぁ！残業代でホクホクだぜぃ」
見たいな意見が以前このスレで出てたな。
692:仕様書無しさん
07/11/11 10:51:47
>>686
判っていて敢えて書いてんだよｗ
693:仕様書無しさん
07/11/12 18:56:00
679はガンダム抜きにしても
見事に当たってる
694:仕様書無しさん
07/11/13 01:01:57
ところで桁ってどの部分の桁なんよ
pic？
レコードの構成を考慮してソースをレビューすると突っ込まれると思う
695:仕様書無しさん
07/11/14 00:34:32
00123456
~~
696:仕様書無しさん
07/11/15 22:05:45
>>694
自分のいるとこだと固定長の電文をただDBにぶち込むだけの
アホみたいな通信制御システム作ってるコボラ風な奴が
やたらと桁数で喚いていたことがある
697:仕様書無しさん
07/11/17 02:41:39
電文........
懐かしい響きだな。
698:仕様書無しさん
07/11/20 19:02:36
コボラ、元気か？
699:団塊コボラ
07/11/20 19:57:29
呼びましたか？
最近、ネタ切れで....
700:仕様書無しさん
07/11/21 23:41:41
そういやコボルってソートどうやって実装するの?
外だしか?
701:仕様書無しさん
07/11/22 04:07:50
言語仕様にあったりする。でもたいがい外。
702:仕様書無しさん
07/11/22 07:54:14
RDBにつなげているからOrder一発なのに
一生懸命並び替えている馬鹿が居たなー(遠い目)
703:仕様書無しさん
07/11/22 13:07:52
>>700-701
COBOL でできること以外に興味持たないと、楽そうだねー
>>702
ソートのロジックを考えようとした分、プログラマとしてはましな気がする。
704:仕様書無しさん
07/11/22 19:04:58
趣味ならいいけど、仕事でやられたら刺したくなるが
705:仕様書無しさん
07/11/22 21:09:53
>>702
ORDER BY よりクライアントでソートのほうが当然速いわな。
何で開発しているかしらんけど、多くの言語にはソートの機能は実装されている。
706:仕様書無しさん
07/11/22 21:43:00
先頭の一部しか必要ないときも全部ネットワーク越しに取ってきてから
ソートして、いらないところを捨てるの?
707:仕様書無しさん
07/11/22 22:00:41
RDBならインデックス次第だな。
708:仕様書無しさん
07/11/22 22:12:43
業務ではVB6で挿入ソートを自作したことはある。
709:仕様書無しさん
07/11/22 22:25:35
寒いな、コボラ
何も変わってないじゃないか
710:仕様書無しさん
07/11/22 22:34:33
最近コボラに殺意を覚えるようになってきた・・・。
あいつの作ったシステムはモデルとビューと
データが全て渾然一体だ・・・。糞な設計で苦しんでる
くせに、オペレーターの人気を取ろうとして、しょうもない
機能を追加してさらにカオスを増大させやがって・・・
まじで殺したい。。。
711:仕様書無しさん
07/11/22 23:18:37
>>705
こぼらか、あるいはヴビ厨か？
712:仕様書無しさん
07/11/22 23:35:21
コボルなら挿入ソートが限界かな、言語でサポートされてるの
使ったことないよ。icamnでokか
vbのソートはリストコントロールに突っ込めばokだっけ?
なにもかも懐かしい
713:仕様書無しさん
07/11/22 23:36:44
あICEMANか
714:仕様書無しさん
07/11/23 00:08:42
>>705
RDBのチューンすら出来ないコボラーは黙って氏ね!
715:仕様書無しさん
07/11/23 13:01:50
コボラーに回ってくるころにはTABLE設計完了してるので
もともと手がでましぇん
716:仕様書無しさん
07/11/23 13:47:33
うちはコボラがISAMで設計してんだぞいい加減にしろ
717:仕様書無しさん
07/11/23 17:42:56
>>710
殺りたきゃお好きにどうぞ。
自分のコボラ上司と同一人物であることを祈る。
718:仕様書無しさん
07/11/24 13:43:08
誰か、これこそは「至高の言語」を挙げろ。
719:仕様書無しさん
07/11/24 13:43:35
日本語
720:仕様書無しさん
07/11/24 13:50:32
日本語だめだ
あいまいすぐる
721:仕様書無しさん
07/11/24 13:57:36
だが、そこがいい
722:仕様書無しさん
07/11/24 14:02:28
それはあいまいなのに通じてしまう
利用者がすごいのであって
言語としてはどうなんだろう
723:仕様書無しさん
07/11/24 15:16:00
>>720
まるで、多ヶ国語をマスターしているかのような物言い。
724:仕様書無しさん
07/11/24 16:27:15
「至高の言語」..."幼女"を20通りの表現であらわすことができる
あれか?
725:仕様書無しさん
07/11/24 17:21:35
>>723
プログラミング言語含めれば多言語マスターしてる
プログラミング言語のあいまいさ＜自然言語のあいまいさ
726:仕様書無しさん
07/11/24 18:28:17
多ヶ国語
727:仕様書無しさん
07/11/24 18:30:28
>>726
タガログ語？
728:仕様書無しさん
07/11/24 19:33:32
誰か、これこそは「究極の言語」を挙げろ。
729:仕様書無しさん
07/11/24 20:26:43
日本語
730:仕様書無しさん
07/11/24 21:04:04
１行だけ「現行と同じ機能を実装すること」と書いておき、
ひたすら「死んでもﾔﾚ」と事あるごとに怒鳴りつければ出来上がる。
なんて便利な言語なんだろうなー（棒
731:仕様書無しさん
07/11/24 21:12:06
それ日本語に限ったことじゃねぇだろ。
732:仕様書無しさん
07/11/24 21:12:53
>>725
多ヶ国語
733:仕様書無しさん
07/11/24 21:22:53
>>730>>731
ハートマン軍曹が一人いればOKだな。w
734:仕様書無しさん
07/11/26 21:39:08
おい、コボラ！ボコルぞ！
735:仕様書無しさん
07/11/28 01:26:36
うちの元システム管理者（<> SE, PG）はコボル崇拝者だった。
何の言語もわからないのに、
爺「あそこの業者はVBしか使えないからいかん。COBOLで作れるところを探せ」
俺「CかJAVAでええやん」（俺もVB「しか」使えない業者はいらん）
爺「Cなんてバグだらけになる。JAVAはウェブだろが」
爺「俺はSEだからプログラムなんか作れんが、COBOLとDB2で作ったものしか認めん」
爺「SQLを使うこと自体、あの業者は頭が悪い」
俺「は？ DB2でもSQLを使うんだが、それはいいのか？」
爺「おまえは何もしらないのか。SQLはマイクロソフト、DB2はIBMだろ。ちゃんと勉強しとけ」
俺「一度くらい本屋のPC棚みてこい。SQLハンドブックの対応RDBを３回音読してこい」
などなど、いろんな珍問答をしてきたものだ。
736:仕様書無しさん
07/11/28 01:30:44
SQLはSYBASEだろうが
737:仕様書無しさん
07/11/28 01:38:51
>>735
COBOLを書くコボラの痛さはわかるが、プログラム自体知らずになぜCOBOL信者になるんだよｗ
738:仕様書無しさん
07/11/28 03:38:30
そこがコボラ達の恐ろしさ。
739:仕様書無しさん
07/11/28 07:41:53
Cだとポインタ、Javaだとオブジェクト指向の概念といろいろハードルがあって、
あまりにもレベルの低い奴は淘汰される。
ところはCOBOLは馬鹿でもできるから馬鹿が淘汰されない。
もちろん、できる奴はCOBOLなんかで満足できずに他所へ行く。
したがって、コボラーには馬鹿しか残らない。
740:仕様書無しさん
07/11/28 19:04:54
ぶぶぶVBは？
741:仕様書無しさん
07/11/28 19:56:49
似たり寄ったり
742:仕様書無しさん
07/11/28 23:03:25
>>741
それ言うなら、ソリューションやってる時点で
C++でもJAVAでもVBでもCOBOLでも
どんぐりの背比べ。
743:仕様書無しさん
07/11/28 23:36:09
さすがにCOBOLと言うどんぐりは小さすぎな希ガス
744:仕様書無しさん
07/11/29 22:25:37
>>742
>ソリューション
とかぬかす奴が「C++」の0.1%も理解しているとも思えんのだが。
745:仕様書無しさん
07/11/29 22:34:31
VSのソリューション？
前と同じにワークスペースじゃ駄目なのかねぇ…
746:仕様書無しさん
07/11/30 02:03:25
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
あほくさ
747:仕様書無しさん
07/11/30 02:07:41
ちゅうか、「ＩＴソリューション」全般のこといってんじゃまいか？
748:仕様書無しさん
07/11/30 02:14:09
やっぱ、「C（C++）が偉い」という半可通の誤解は根強いな。
749:仕様書無しさん
07/11/30 20:07:48
最近入った現場。
横長だが数が足りてない。
開発初期から分かっていたらしい。
なんだこの設計。
750:仕様書無しさん
07/11/30 22:19:33
一回承認されたものはどんな不都合があっても、それがどれだけ早期発見であっても直さない。
それがコボラ。
751:仕様書無しさん
07/12/01 08:27:21
おい、コボラ
752:仕様書無しさん
07/12/01 09:51:14
>>751
なんでしょ？
753:仕様書無しさん
07/12/01 10:50:12
結婚してくれ
754:仕様書無しさん
07/12/01 13:19:06
>>749
ご愁傷様です
755:仕様書無しさん
07/12/01 17:13:33
>>744
C++得意なんだ。すごいね。
756:仕様書無しさん
07/12/01 17:38:25
やっぱりCOBOLと連携するDBとかって横長DBにしかできんの？
コボラの気持ちが分からないので、売り上げ管理のようなシステムで
「社員IDと社員名と代理店IDと代理店名と所属支社名と所属IDはいらないですよね？全部マスタファイルがあるわけですからID→固有名の取得はテーブル結合で・・・」
とか話したのに、出来上がったデータは横長で全部入ってた。
社員ID―社員名、のような社員マスタがあるうえ
社員ID→代理店ID―代理店名の代理店マスタもあるので（１対ｎ：→ね）
代理店IDさえ持ってれば処理できるはずなのに・・・うーん。
ホスト上のレコードの持ち方もあるのだろうし、日程も無いからそのまま突っ込んだけどさ。
757:仕様書無しさん
07/12/01 17:57:45
「テーブル結合」なんていう専門用語を使ったのが失敗だな
758:仕様書無しさん
07/12/01 18:05:40
コボラはね、連結した結果を保存する事しか考えないんだよ。
確かにマスターは有るよ？ でもそれを結合した結果は「せっかくだから保存しちゃえ！」って考えるんだよ。
だって、売上げデータを集計するとかそれを帳票印字するとかさ、売上げデータに全部入っていれば、
売上げデータだけをぐりぐり回してブレイクキーで操作すれば帳票項目が全部揃うでしょ？簡単じゃん！って思うんだよ。
コボラの脳みそはスタック一個分しかないんだよ。
759:仕様書無しさん
07/12/01 19:23:05
何か1レコードupdateするとそれを使ってるテーブルも一斉にupdateしたりするよな。
760:仕様書無しさん
07/12/01 20:59:18
コボラじゃなかったけど、やっぱりテーブルの連結ができないベテランと仕事をしたことがあるよ。
テーブルの連結以前にSQLをかけなくてAccessのGUIで、マウスでリレーションを書いて、それでSQLを生成させてた。
Accessでも複数のテーブルの連結は可能だろうけど、それさえも使えてなかったみたいで、テーブルは二つまでしか連結してなかった。
でも、仕事は、新規の案件じゃなかったから、データは普通に正規化されてて、複数のテーブルを連結させなきゃならない。
で、どうしたかというと、WKTBL1,WKTBL2,WKTBL3…と、作業用のテーブルを作っておいて、
DELETE FROM WKTBL1
INSERT INTO WKTBL1 …
SELECT…FROM TBL1, TBL2
:
DELETE FROM WKTBL2
INSERT INTO WKTBL2 …
SELECT…FROM WKTBL1, TBL3
と、作業用のテーブルを何段か経由して、一個ずつテーブルを連結していくっていう、目からうろこのテクニックを使ってますたよ。
ほかにも考えられないようなことをいろいろしてたので、5年くらいまえのPCに載ってるシステムを、新しいPCに変えて納品するって仕事だったのに、以前のシステムより遅くなったりとかすごいことになってた。
761:仕様書無しさん
07/12/01 22:18:49
なんていうか、速度を気にしてコードをかけない奴は糞だが、コボラ出身者にはそういうのが割と多いって所もありそうだな。
メインフレームに頼り切るから…
762:仕様書無しさん
07/12/01 23:23:53
ここは日本なのに「アメリカでは右側通行だ！世界の常識をしらんのか！」とか言って
右側走ってるようなもんだよなぁ・・・・
763:仕様書無しさん
07/12/01 23:40:53
一バイトに数値が0から9までしか持てないって考えてるのはなんなの？
昔はアセンブラが専門だったって言ってたけどありゃ嘘だな。
764:仕様書無しさん
07/12/02 00:56:02
>>763
うーん
URLﾘﾝｸ(ja.wikipedia.org)
このへん
765:仕様書無しさん
07/12/02 01:27:12
bcdにしたって二桁だけど・・・
766:仕様書無しさん
07/12/02 02:46:12
一度入ったらまず更新されない、しかもいつも結合して使うと分かってるのなら、
一緒にしちゃって横長にした方が使う人が楽だと考えるんじゃないか？
整合性を確実に取りたかったらトリガー使えばいいし。
767:仕様書無しさん
07/12/02 04:32:21
>>760
Viewも知らんのかw
768:仕様書無しさん
07/12/02 09:51:37
>>763
ホスト用のアセンブラ(旧世代RPGとか)だな。
769:仕様書無しさん
07/12/02 17:56:01
ゾーンだよゾーン
770:仕様書無しさん
07/12/02 19:28:37
流星人間
771:仕様書無しさん
07/12/02 21:15:03
>>767
コボラーをかいかぶり過ぎ。
SQLの知識なんて初級シスアド持ってる事務のねーやん以下。
772:仕様書無しさん
07/12/02 22:24:07
＞ホスト用のアセンブラ(旧世代RPG
･･？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？
773:仕様書無しさん
07/12/02 23:39:56
>>772
まぁ、今時の若者がRPGのソース見たらアセンブラと勘違いするかも知れん(苦笑)
774:仕様書無しさん
07/12/02 23:41:57
Role Playing Gameしか知らないかも。
775:仕様書無しさん
07/12/03 00:22:01
>>773
今もやってますが？
776:仕様書無しさん
07/12/03 06:47:29
>>775
仕事結構ある？
ILEは使った事無いけど大丈夫かね？
777:仕様書無しさん
07/12/03 11:59:23
漏れの周りは未だにRPGⅢだなぁ。
ILEはサッパリ。
正直フリーフォーマット言語(?)使っていいならILE RPGよりも
C/C++かJavaを提案するが。
778:仕様書無しさん
07/12/03 23:22:19
>>776
閉鎖ドブス地帯で同じようなルートでずぶずぶやるなら食える程度に
もうじき東京行きますが
今のＩＬＥだとほとんど標識使わずすっきり書けますな
>>777
フリーフォーマットってほどでも
779:仕様書無しさん
07/12/05 19:30:58
Perlの文字コード変換ライブラリと、
C/C++/gcc/Win32でカーネル開発やmozillaに貢献は、
果てしない技術レベルの壁がある。
まぁ文字コード関係も、大きな努力と集中力を要する
大変な作業であることも確かだが…。
Webの大部分はパブリッシング、デザインの世界だからね。
技術先行でやってるとこなんてごくわずかで、今後コモディティ化が
進めば技術者にとってはより住みにくい世界になるだろうね。
780:仕様書無しさん
07/12/05 19:42:09
>>779
さっきからいろいろなスレに何コピペしてんの？
発端は
ｽﾚﾘﾝｸ(prog板:218-231番)
か？
781:仕様書無しさん
07/12/05 21:30:20
火病ってマルチポストとかチョンかよ
782:仕様書無しさん
07/12/12 20:53:01
横長から縦長にコンバートするプろグラム作成中…
783:仕様書無しさん
07/12/13 21:08:05
社名変更したら顧客番号も変更するってどんなアホな設計だよ・・・
まじで新で欲しい・・・
784:仕様書無しさん
07/12/14 13:05:24
世の中にはな、inputが無いoutputを定義する馬鹿がいるんだから…。
何で顧客登録しないでいきなり課金データが出てくるかなぁ。orz
785:仕様書無しさん
07/12/15 00:28:31
>>783
よ～、判らん。何で社名変更が顧客番号の変更に繋がる？
そういえば顧客名を音別に分けてコード化していたとこもあったが。
786:仕様書無しさん
07/12/15 01:54:55
変更前後で区別したい理由があったのかな？
787:仕様書無しさん
07/12/15 17:44:52
顧客番号が変わるとダメになる
設計もなんだよな。
788:仕様書無しさん
07/12/15 18:58:45
じゃあ何を主キーにするんだよ
789:仕様書無しさん
07/12/15 19:41:34
俺コード
790:仕様書無しさん
07/12/15 20:21:19
君の人生
791:仕様書無しさん
07/12/15 21:21:11
連番でIDふっちゃえばいい。だから俺コードは割りと正解。
業務で使う項目を主キーにする神経がわからん。
業務ルールなんてお客さんの都合で変わるじゃん。
792:仕様書無しさん
07/12/15 22:35:25
業務側に振り回されるのを防ぐのなら、俺コードをDB内部で使って、俺コードと客コードの対応テーブルも用意しとけば良いってことか。
793:仕様書無しさん
07/12/16 01:12:04
>>792
俺コードと客コードの対応テーブルなんていらない。
主キーが俺コード。客コードは単なる属性のひとつ。
どうしても気持ち悪ければNOT NULL と ユニーク制約つけときゃいい。
794:仕様書無しさん
07/12/16 11:20:04
そして元の木阿弥
795:仕様書無しさん
07/12/16 18:19:58
プログラムより業務と言い張る社内コボラーは
PCのヘルプデスクや障害対応がまったく出来ない。
ヘルプも業務の一環ですよ？
誰でも出来るCOBOLだけうれしそうにやってないで
そろそろ他の業務も覚えて下さい。
796:仕様書無しさん
07/12/17 10:56:15
>>794
どこが？他テーブルの外部キーが
俺コードってだけで大違いじゃん。
797:仕様書無しさん
07/12/17 18:36:20
他テーブルには俺コードと客コード両方持つのか？
798:仕様書無しさん
07/12/17 23:25:53
>>797
なぜそういう発想になるのかさっぱりわかんない。
だから客コードは名称とか一緒のただの属性で、
主キーは俺コード（つかただの連番、なんちゃらIDとか）
でいいじゃんて話だよ。なんで伝わんないかなあ。
まあ他テーブルが売上データとかで、
売上日当時の客コードを過去データとして
スナップショット取っておくとかならわかるけどな。
799:仕様書無しさん
07/12/17 23:35:45
サロゲートキーっていう言葉がある
800:仕様書無しさん
07/12/18 00:58:15
>>799
それそれ。ってあまり好きな言葉じゃないんだけど。
だって代理でもなんでもない、システムが稼動する限り
変わらない事が保証される、本当のキーじゃん。
業務ルールの都合で変わる可能性が0じゃないもんを
主キーにするのがおかしい。
801:仕様書無しさん
07/12/18 02:02:47
>>800
>>783に対してのレスの流れだと、変わらない事が保証されないわけで。
だったら変わる部分と本当のキーの対応を別テーブルに…ってことかと思ったんだが、違うのか？
802:仕様書無しさん
07/12/18 02:55:11
>>801
だから、変わる可能性がある、業務に使うコードなんか
主キーにするから泣きを見るっていってんじゃん。
だから業務で使うコード（783なら顧客番号）じゃなくて
俺コードをPKにすりゃいいっていってんのに
それがなんで別テーブルで管理って話になるんだ？
顧客テーブル
・顧客番号（PK）
・顧客名
・住所
っての状態を
顧客テーブル
・顧客ID（PK 自動採番）
・顧客番号
・顧客名
・住所
にすりゃ、顧客名が変わると同時に顧客番号が
変わるって業務ルールでも何の問題もないし
別テーブルで管理なんて冗長な事いらんでしょ。
ここまで説明せんといかんとは。
人の事コボラーとかいって笑えないぜ。
あまり長文かかすなよ。自分で自分がきもいわ。
803:仕様書無しさん
07/12/18 07:02:00
新旧の顧客番号が一緒に飛んでくる。
804:仕様書無しさん
07/12/18 07:45:00
>>803
>SELECT * FROM こきゃくますた
+－－－－－－+－－－－－－+－－－－－－+－－－－－－+
| 顧客番号１ | 顧客番号２ | 顧客番号３ | 顧客番号４ | ・・・・
+－－－－－－+－－－－－－+－－－－－－+－－－－－－+
＿＿＿_
／ ＼
／ ─ ─＼
／ （●） （●） ＼
| （__人__） | ＿＿＿＿＿＿＿_
＼ ｀ ⌒´ ,／ | | |
ノ ＼ | | |
／´ | | |
| ｌ | | |
ヽ -一ー_~､⌒)^),-､ | |_＿＿＿＿＿＿__|
ヽ ＿＿＿＿,ノγ⌒ヽ)ニニ-￣ | | |
805:仕様書無しさん
07/12/18 08:35:23
>>804
おお～！アタマ良いなw
806:仕様書無しさん
07/12/18 17:30:02
一挙解決じゃん。
頭いいな>>804
807:仕様書無しさん
07/12/18 18:06:08
>>804
で横長ＤＢができるのかw
808:仕様書無しさん
07/12/18 21:32:45
見事にオチがつきました。ﾁｬﾝﾁｬﾝ w
809:仕様書無しさん
07/12/18 21:53:01
>>802
新規で作るならそれでいいけどね、、すでに顧客番号が主キー
になってしまってて、糞設計をカバーするための無理な改修と
複雑な迂回経路ロジックが絡まって、崩壊寸前のカオス状態の
データをどうすっかなーという愚痴なわけで・・・
結論としてはコボラー士ね。これ。
810:仕様書無しさん
07/12/19 02:29:42
先日、うちのシステム部門が作っている新規システムのデモに参加した。
品番や顧客コードの変更に弱く、品番ツリー（部品表）も実務に耐えられる機能を持っていなかった。
出しゃばりの俺が、システムの同期に設計を見せてもらったらひどすぎた。
業務キーを主キーにするのは当然のこと、
部品表を表すための品番構成マスタもルートに対しての参照と構成レベルで表現されていた。
n:nの自己参照を関連テーブルで作って再帰ツリーにする方法がわからなかったらしい。
現在、趣味グラマの俺（生管）が「楽々ERDレッスン」を使って、プロジェクトチームに講習会を行っている。
どんな会社だ。
811:仕様書無しさん
07/12/19 03:03:38
>>810
製造業でひどい設計のDBだと死にそうだなあ。
俺は物流ばっかりだからひどいのも何度も見てるけど
まあなんとかなってたよ。
812:仕様書無しさん
07/12/24 12:54:47
>>再帰ツリーにする方法がわからなかったらしい
講習会よりも転職、異動を薦めるほうが....
813:仕様書無しさん
07/12/24 21:36:28
───── ― - --
── /⌒ヽ, ─────
￣￣ / ,ﾍ ヽ∧＿∧ ￣￣￣￣￣￣￣￣ , ” ' ‐ ,
￣￣ i .i ＼ （ ´Д｀）ヽ, ___,, __ ＿ ,, - _―" ’. ' ・, ’・ , /∧＿∧
─ ヽ勿 ヽ,__ j i~"" ＿ ― ＿: i ∴”_ ∵, ）） →>>コボラ
＿＿＿＿＿＿ ヽ,, / / __,,, -- "" ─ "ー ・, ； ; - 、・ r=-,/⌒ ~ヽ~,
──── ヽﾉ ﾉ,イ ── ― - i ｙ ﾉ' ﾉi j |
──── / /,. ヽ, ─ i,,___ノ /／
＿＿＿＿＿＿ 丿 ﾉ ヽ,__,ﾉ ＿＿＿ ＿ _ _ ,' ゝi
j i ／ y ノ
＿＿＿＿＿ 巛i~ ＿＿＿＿ ＿ / ／~／
i < /
──── _ _ ヽ, ＼
// | | 巛 / ヽ_ ）
── // | | ＝＝＝┐ i （~＿ノ
// | | | | ﾉ /
~ ~ | | ﾉ /
＝＝＝┘ (~ ソ
~￣
..... ............................ ......... . . ... ....... .
: :: ::::: :::::::::::::::::::::::::::: ::::::::::: :: : : : :::::::::: :::::: :: : : :
814:仕様書無しさん
07/12/24 22:17:52
───── ― - --
── /⌒ヽ, ─────
￣￣ / ,ﾍ ヽ∧＿∧ ￣￣￣￣￣￣￣￣ , ” ' ‐ ,
￣￣ i .i ＼ （ ´Д｀）ヽ, ___,, __ ＿ ,, - _―" ’. ' ・, ’・ , /∧＿∧
─ ヽ勿 ヽ,__ j i~"" ＿ ― ＿: i ∴”_ ∵, ）） →>>813
＿＿＿＿＿＿ ヽ,, / / __,,, -- "" ─ "ー ・, ； ; - 、・ r=-,/⌒ ~ヽ~,
──── ヽﾉ ﾉ,イ ── ― - i ｙ ﾉ' ﾉi j |
──── / /,. ヽ, ─ i,,___ノ /／
＿＿＿＿＿＿ 丿 ﾉ ヽ,__,ﾉ ＿＿＿ ＿ _ _ ,' ゝi
j i ／ y ノ
＿＿＿＿＿ 巛i~ ＿＿＿＿ ＿ / ／~／
i < /
──── _ _ ヽ, ＼
// | | 巛 / ヽ_ ）
── // | | ＝＝＝┐ i （~＿ノ
// | | | | ﾉ /
~ ~ | | ﾉ /
＝＝＝┘ (~ ソ
~￣
..... ............................ ......... . . ... ....... .
: :: ::::: :::::::::::::::::::::::::::: ::::::::::: :: : : : :::::::::: :::::: :: : : :
815:仕様書無しさん
07/12/25 02:25:48
同じ顧客コードがついてるけど別会社です、とか
別の顧客コードがついてるけど同じ会社です、とか
それに対応するシステムを作れ、とか
俺は悲しい
816:仕様書無しさん
07/12/25 10:27:03
>>815
新規案件だったら簡単な話だけど
そうじゃなさそうだなこの流れだと。
そういうの死ぬよなー。
俺は商品周りでそれやられた。
817:仕様書無しさん
07/12/25 20:41:03
顧客番号の取り方で、ある番号帯ではインクリメントしていき、
別の番号帯ではデクリメントしていき、そしてまた桁の繰り上がり
が上がったり下がったりするようなのを自慢げに語られるわけです。
俺はこんなに複雑なもんを組んで、桁数が足りないのをカバー
してんだぞと・・。もう市ねといいたいです。
818:仕様書無しさん
07/12/26 10:09:21
>>817
それってどういう意味があるんだろう？桁数は変わらないような。
顧客番号から顧客数を推測されるのを回避できそうだと思うけれども。
819:仕様書無しさん
07/12/27 00:13:17
>>818
顧客番号は社内のみで使用
820:仕様書無しさん
07/12/27 00:21:42
いままさにおれの状況だ…
なんで顧客番号のほかに「キー」なんてｶﾗﾑがあるんだよ、orz
821:仕様書無しさん
07/12/27 22:23:43
>>815
前提なら悲しくない。
そういう前提の仕事をできないお前がクズ。
しね。
822:仕様書無しさん
07/12/28 23:25:35
その前提自体が悲しい。
823:仕様書無しさん
07/12/29 04:37:02
>>822
この程度で悲しんでたら
仕事になんねーじゃん。
泣くのはこの前提がカットオーバー
間際に発覚とかそういう場合だろ。
824:仕様書無しさん
08/01/03 06:08:21
コボラではないが、
DEVELOPER(PL/SQL)とVB6.0が共存するシステムで
CSV取り込みをDEVELOPERで
バッチをVBで
やるとか言われて仰天した。
なんか通じるものがある。
825:仕様書無しさん
08/01/03 18:40:53
今設計やってるんだが、
コボルからの移行なんだがDBを横長にしないとぶち切れる。
脳みそついてきてないんだろうな・・・。
ものすごく簡単なリレーションも理解できないから
同じ項目を何箇所にも持たせようとしたりして突っ込みに疲れる
826:仕様書無しさん
08/01/03 18:46:04
同じ物を何カ所も持ってたり、更新のたびにあちこちで再計算しまくるのな。
827:仕様書無しさん
08/01/03 18:47:04
あがってきたdb設計をおれが全部直してる。
全部こっちでやろうかな・・・
828:仕様書無しさん
08/01/04 13:49:56
>>827
そうしろ。
３日から大変だな。
829:仕様書無しさん
08/01/04 22:48:03
おい、ここか
コボラじゃないふりしてコボラをばかにしてる集会所は
830:仕様書無しさん
08/01/04 22:55:10
>>829
そうなんだよ。
お前もいつまでも演技してんな。
831:仕様書無しさん
08/01/05 08:12:26
コボラがガオー
832:仕様書無しさん
08/01/05 19:46:52
,._.,
‘^^
833:仕様書無しさん
08/01/05 19:47:41
,._.,
‘^^
834:仕様書無しさん
08/01/05 22:46:45
>>826
＞更新のたびにあちこちで再計算
トリガー使えばなんてことない。
ちまちま結合してる余裕がないのです。
データ構造を熟知してない人でも使えてレスポンスの良い横長の結果が重要なのですよ。
ケースバイケースでやらないと某スレで言われてるみたいに
プログラムは単純作業って言われちゃいますよ。
835:仕様書無しさん
08/01/05 23:28:37
>ちまちま結合してる余裕がないのです。
トリガー内で結合してるよね？
>データ構造を熟知してない人でも使えて
コボラーに使わせる必要が無い^^
836:仕様書無しさん
08/01/06 00:11:38
>>834
半可通乙
837:仕様書無しさん
08/01/06 00:57:27
>>835
＞トリガー内で結合してるよね？
横長DBをSELECTするときに結合する必要がない。
＞コボラーに使わせる必要が無い^^
それで済んだら世話ない。
838:仕様書無しさん
08/01/06 03:37:20
団塊でてこい。
839:仕様書無しさん
08/01/06 06:21:19
倖田來未とＳＥＸ
相武沙希と握手
ギャル曽根と大食い勝負
お前らどれする？
840:仕様書無しさん
08/01/06 10:19:58
>>837はリレーションわからないコボラーの典型だな
841:仕様書無しさん
08/01/06 10:24:00
>>834
>>837
そういう時はビューを使いましょう
842:仕様書無しさん
08/01/06 23:38:49
>>840
リレーションをわかってないのは君だ。
リレーションシップな。
843:仕様書無しさん
08/01/07 01:20:44
リレーションとリレーションシップってどう違うの？
リレーショナルデータベースっていうくらいだからリレーションでもいいと思うんだが
844:仕様書無しさん
08/01/07 01:32:09
ざっくりとした説明だが、
リレーション = テーブル、だ。
出直してきなさい。
845:仕様書無しさん
08/01/07 03:41:19
半可通もいい加減に.......
846:仕様書無しさん
08/01/07 04:11:48
>>845
リレーション = テーブルってのも言葉足らずで
不正確なのはわかっとるわい。
リレーションを関連とか思ってる奴には
とりあえずこれでいいだろこれで。
847:仕様書無しさん
08/01/07 04:51:58
>>846
あんたが「リレーションについて知ってるぞ」って主張したいのは
分かったけど、>>841はスルーなの？
848:仕様書無しさん
08/01/07 05:05:17
>>847
へ？ビュー使えばいいじゃん。
あ、そうか。俺、>>834でも>>837でもないです。
コボラー叩きしたつもりで恥さらしてる>>840が
痛々しいので横から大きなお世話焼こうかなって
思っただけです。
849:仕様書無しさん
08/01/07 05:34:51
まぁ、前後との関係で読み取れる範囲だと思うよ。840は。
実際、841は察してるしね（OR 同じ間違い）。
850:仕様書無しさん
08/01/07 05:42:30
>>849
前後の関係っていうか、841が察してるとかは知らんけど、まぁわかるわな。
実際とてもありがちな誤用なので。
851:仕様書無しさん
08/01/07 07:34:44
>>846
>>リレーション = テーブルってのも言葉足らずで
>>不正確なのはわかっとるわい。
なら、>>840がなんで叩かれるんだろう？
852:仕様書無しさん
08/01/07 07:53:47
わぁ＞＜
釣れてる＞＜
・・・仕事いってきます
853:仕様書無しさん
08/01/07 10:05:15
>>851
リレーションを関連の意味で使ってるのは
明らかな間違いなのと、
この間違い自体はよくある話だからいいとしても
それを他人を叩く文脈で使ってるのが凄く恥ずかしいから。
民主党なみのブーメラン現象だろう？
854:仕様書無しさん
08/01/07 20:50:25
ビューでもジョインでもどっちでもいいが
ボラクルCBOのアホさ加減には辟易する
855:仕様書無しさん
08/01/19 21:37:29
ファビョリジニー
856:仕様書無しさん
08/01/25 01:37:56
>>854
刺ねよ、クソコボラ。
857:仕様書無しさん
08/01/25 21:41:12
IT業界に３０年以上いますが、
プログラミングしかやったことがありません。
言語はコボルしかやったことがありません。
最近はコボル人口が激減しているのでとても待遇がいいです。
今年のボーナスの合計額は３７８万円でした。
こんなにもらって申し訳ない気持ちでいっぱいです。
858:仕様書無しさん
08/01/25 23:07:05
そういえばエボラの無毒化に成功したみたいだね。
859:仕様書無しさん
08/01/26 20:56:13
コボラの無害化は....無理か
860:仕様書無しさん
08/01/26 21:12:43
この前引き継いだシステムはコボルで設計した横長ＤＢを
そのままSQLに突っ込んだだけのもので、それを複雑な
ビューとストアドで正規化されているテーブルのように見せ、
使うときはそのビューを結合して使うのだった。いい加減に城。
861:仕様書無しさん
08/01/26 23:06:23
そのビューのレイアウトにコンバージョンすればいんじゃね？
862:仕様書無しさん
08/01/26 23:16:06
参照はそれでいいけど
更新はどうすんだよ？
糞テーブル残してトリガ更新か？
863:仕様書無しさん
08/01/27 02:18:01
お前らよく聞け。
オープン系が出てくる遥か前にコボラは市場を席巻している。
もう、お前らの負けは確定的。
864:仕様書無しさん
08/01/27 23:26:08
>863
「自動車? この馬車全盛の世の中でそんなもん売れるわけないだろう」
(フォードが融資を頼みに行った銀行からの断り文句)
865:仕様書無しさん
08/01/27 23:49:28
まぁ、馬車と自動車ほど
汎用機とオープン系は違わないからなー。
利用者にとっては。ユビキタスだな。
866:仕様書無しさん
08/01/28 04:29:02
俺、コボラだけど
JAVAでサーブレットも
PERLでCGIも
Cで組み込みも
VB,DELPHIでC/Sも
ついでにPL/SQLとかDBMAGICなんかもできるよ。
言語をして、どれがいいとかわけわかりません。
ただ一ついえるのは
コ ボ ル が 一 番 楽 で 金 に な る 。
ってこと。
その次は組み込みかな。
JAVA案件は貧乏人がやればいい ｗ
867:仕様書無しさん
08/01/28 04:32:23
Oracle案件は半可通が多くて困ることが結構ある。
特にパフォーマンスに関しては
「このプロジェクトで一番詳しい」
とか言われてる奴がど素人だったりするから ｗ