コボラは横長DBがお好き 2カラム目at PROG
コボラは横長DBがお好き 2カラム目 - 暇つぶし2ch720:仕様書無しさん
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
1行だけ「現行と同じ機能を実装すること」と書いておき、
ひたすら「死んでもヤレ」と事あるごとに怒鳴りつければ出来上がる。

なんて便利な言語なんだろうなー(棒

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を3回音読してこい」

などなど、いろんな珍問答をしてきたものだ。

736:仕様書無しさん
07/11/28 01:30:44
SQLはSYBASEだろうが

737:仕様書無しさん
07/11/28 01:38:51
>>735
COBOLを書くコボラの痛さはわかるが、プログラム自体知らずになぜCOBOL信者になるんだよw

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
ちゅうか、「ITソリューション」全般のこといってんじゃまいか?

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―代理店名の代理店マスタもあるので(1対n:→ね)
代理店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
閉鎖ドブス地帯で同じようなルートでずぶずぶやるなら食える程度に
もうじき東京行きますが
今のILEだとほとんど標識使わずすっきり書けますな

>>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 こきゃくますた

+------+------+------+------+
| 顧客番号1  | 顧客番号2  | 顧客番号3  | 顧客番号4  | ・・・・
+------+------+------+------+

         ____         
       /      \        
      /  ─    ─\     
    /    (●)  (●) \               
    |       (__人__)    | ________    
     \      ` ⌒´   ,/ | |          |  
    ノ           \ | |          |  
  /´                 | |          |  
 |    l                | |          |
 ヽ    -一ー_~、⌒)^),-、   | |_________|   
  ヽ ____,ノγ⌒ヽ)ニニ- ̄   | |  |      

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
で横長DBができるのか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 y  ノ' ノ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 y  ノ' ノ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
そうしろ。
3日から大変だな。

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
倖田來未とSEX
相武沙希と握手
ギャル曽根と大食い勝負

お前らどれする?

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業界に30年以上いますが、
プログラミングしかやったことがありません。
言語はコボルしかやったことがありません。
最近はコボル人口が激減しているのでとても待遇がいいです。
今年のボーナスの合計額は378万円でした。
こんなにもらって申し訳ない気持ちでいっぱいです。


858:仕様書無しさん
08/01/25 23:07:05
そういえばエボラの無毒化に成功したみたいだね。

859:仕様書無しさん
08/01/26 20:56:13
コボラの無害化は....無理か

860:仕様書無しさん
08/01/26 21:12:43
この前引き継いだシステムはコボルで設計した横長DBを
そのまま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案件は貧乏人がやればいい w

867:仕様書無しさん
08/01/28 04:32:23
Oracle案件は半可通が多くて困ることが結構ある。
特にパフォーマンスに関しては
「このプロジェクトで一番詳しい」
とか言われてる奴がど素人だったりするから w



最新レス表示
レスジャンプ
類似スレ一覧
スレッドの検索
話題のニュース
おまかせリスト
オプション
しおりを挟む
スレッドに書込
スレッドの一覧
暇つぶし2ch