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