コボラは横長DBがお好き
1 ：おめこ：
コボラは外部キーを横長（XXコード１、XXコード２などを列で持たせる）に持つ習性がある。
３５～４５くらいの人がDB設計するとそうなるよな。RDB台無し。
このスレはそんな馬鹿コボラの目を覚まさせてあげようという、
ちょっとしたボランティア。
チョボラ。
３５～４５くらいの人がDB設計するとそうなるよな。RDB台無し。
このスレはそんな馬鹿コボラの目を覚まさせてあげようという、
ちょっとしたボランティア。
チョボラ。
|
|
|
2 ：おめこ：2006/10/13(金) 22:21:31
ていうか、３５～４５でDB設計なんかしてんなよ。
出世汁！！ボケって感じだけど。
出世汁！！ボケって感じだけど。
この業界、現場でやっと使い物になるようになった奴を
現場から追い出すよな。
現場から追い出すよな。
4 ：仕様書無しさん：2006/10/14(土) 00:03:53
使い物になるようになった奴は追い出さないよ。
使い物にならなかった奴が追い出される『場合がある』だけちゃいますか？
使い物にならなかった奴が追い出される『場合がある』だけちゃいますか？
ひよっこが生意気いっとるな
コーダ卒業してからスレ立てろや
コーダ卒業してからスレ立てろや
コボラーがオープン系でやっていいのはＶＢのコーディングだけ。
最近、ビジネスロジックだけをコボルとかジェイシーエル？で
書けるようなJava/.NETのフレームワーク作れば一儲けできるような気がしてきた。
プログラムの再利用性の次は人材の再利用性ですよ？
書けるようなJava/.NETのフレームワーク作れば一儲けできるような気がしてきた。
プログラムの再利用性の次は人材の再利用性ですよ？
8 ：仕様書無しさん：2006/10/18(水) 21:34:45
おめコボラ
9 ：仕様書無しさん：2006/10/18(水) 21:52:01
異次元コボラ
俺は３５だがＲＤＢ＋ＷＥＢから入ったのでコボラは大嫌い。
11 ：仕様書無しさん：2006/10/19(木) 01:41:31
>>7
臓器以外に再利用できるものがない
臓器以外に再利用できるものがない
>>11
あんなヤニ臭いモノが使い物になるのか？
あんなヤニ臭いモノが使い物になるのか？
13 ：仕様書無しさん：2006/10/19(木) 23:16:14
こぼらは『リレーション』を理解できないらしい。
14 ：仕様書無しさん：2006/10/19(木) 23:18:26
ＰＬに出世したてのコボラが仕切ってるプロジェクトはマジ危ない。
コボラー含有率30%以上の開発は火を噴く。よってコボラーは可燃性物質であると認められる。
16 ：仕様書無しさん：2006/10/21(土) 00:40:35
その３０％の中は１％は放射性同位体だ。
それがあると、核爆発になる。
それがあると、核爆発になる。
横長デブってなに？
18 ：仕様書無しさん：2006/10/21(土) 01:00:02
デブは縦よりも横に長いと飛鳥時代から決まってる。
19 ：仕様書無しさん：2006/10/21(土) 02:19:52
>>16
そんでもって、プロジェクトはβ崩壊
そんでもって、プロジェクトはβ崩壊
20 ：仕様書無しさん：2006/10/21(土) 13:47:45
21 ：非核３原則：2006/10/21(土) 13:51:54
１．コボラを雇わない（持たない）
２．コボラに新人を育てさせない（作らない）
３．コボラに仕事を依頼しない（持ち込ませない）
２．コボラに新人を育てさせない（作らない）
３．コボラに仕事を依頼しない（持ち込ませない）
早い話がコボルすら読めない自称スーパープログラマが吠えるスレ
でいいのか？
こんなこと書くと高確立で
コボラ乙
って言われんだろうけど
でいいのか？
こんなこと書くと高確立で
コボラ乙
って言われんだろうけど
そっか使い物にならんコボラーでもコボルは読めるんだ。目から鱗。
いやだから汎用機に張り付いてりゃ誰も文句いわんて。
いやだから汎用機に張り付いてりゃ誰も文句いわんて。
24 ：仕様書無しさん：2006/10/22(日) 01:41:08
>>20
つまり、汎用機はCOBOLerをさらに増やすための高速増殖炉だということか？
つまり、汎用機はCOBOLerをさらに増やすための高速増殖炉だということか？
コボラーとコラボレーション
コボラーにボコラーれた～
>>1
あ、そーか。横長の原因はそれだったんだ。
もーね。Oracle でね。カラムが1000超えて表作る時にエラー出るから
ってんで表を分けたんだけどね、元の設計がそんな感じだったからさ、
COBOLer ってことね。たしかに作ったのは40代のやつだ。俺も40代
だけどさ。俺は COBOL は全然やったことなくてわからない。
あ、そーか。横長の原因はそれだったんだ。
もーね。Oracle でね。カラムが1000超えて表作る時にエラー出るから
ってんで表を分けたんだけどね、元の設計がそんな感じだったからさ、
COBOLer ってことね。たしかに作ったのは40代のやつだ。俺も40代
だけどさ。俺は COBOL は全然やったことなくてわからない。
そういえば10年ほど前、コボラーSEがACCESSが項目を256個しかもてないとか言って馬鹿にしてたな。
あの頃のオープンの業務系はコボラーSEと新米PGとでシステム作ってた。
今から考えると恐ろしいよｗ
でも・・・この業界には・・・未だにそういう開発が・・・存在する・・・
あの頃のオープンの業務系はコボラーSEと新米PGとでシステム作ってた。
今から考えると恐ろしいよｗ
でも・・・この業界には・・・未だにそういう開発が・・・存在する・・・
29 ：仕様書無しさん：2006/10/23(月) 21:52:45
>>27
そうですよ。
コボラの脳味噌にはリレーションという概念がないのです。
そのため、入力できる明細数が固定だったりする。
『これ１個増やして』っていわれると結構手間だったりする。
縦にしておくと何の変更も要らないネ！
こういう仕様変更で金とるコボラは屑。
そうですよ。
コボラの脳味噌にはリレーションという概念がないのです。
そのため、入力できる明細数が固定だったりする。
『これ１個増やして』っていわれると結構手間だったりする。
縦にしておくと何の変更も要らないネ！
こういう仕様変更で金とるコボラは屑。
419 名前：仕様書無しさん[sage] 投稿日：2006/10/22(日) 01:35:48
create table hoge_geppou(
year char(4),
month char(2),
day1 number(3),
day2 number(3),
：
day31 number(3)
)
引継ぎに来た中国人が原抱えて笑ってた。
create table hoge_geppou(
year char(4),
month char(2),
day1 number(3),
day2 number(3),
：
day31 number(3)
)
引継ぎに来た中国人が原抱えて笑ってた。
31 ：仕様書無しさん：2006/10/23(月) 22:36:52
そうそうコレなんだよ。
コレがコボル病。
YMDをKeyにして１日１レコードが素敵。な場合が多い。
コレがコボル病。
YMDをKeyにして１日１レコードが素敵。な場合が多い。
32 ：仕様書無しさん：2006/10/23(月) 22:38:38
NUMBER(2) ではなく NUMBER(3) というとこもコボル病。
コボル病患者はやたら、予備を取りたがる。
列名 YOBI1,YOBI2 ... なんてのを見たことがある。
飯噴。
コボル病患者はやたら、予備を取りたがる。
列名 YOBI1,YOBI2 ... なんてのを見たことがある。
飯噴。
33 ：仕様書無しさん：2006/10/23(月) 22:39:41
>>30
とても笑えないよ。こういうのに何度出くわしたことか。これから何度出くわすことか・・・
とても笑えないよ。こういうのに何度出くわしたことか。これから何度出くわすことか・・・
35 ：69式フリーPG ◆hND3Lufios ：2006/10/23(月) 23:01:03
おれなんか24個並んでるのを見たことあるぜ。しかもnot nullがついてなくて、
JDBC側から投げるSQLにNVLが24個並んでるの。
JDBC側から投げるSQLにNVLが24個並んでるの。
36 ：仕様書無しさん：2006/10/23(月) 23:08:30
まぁ、何らかの値ならまだ増し。
外部キーを横に２０個とか平気でやるよ奴ら。
で、
同じマスタを２０回ジョイン OR
フロントで行数×２０回LOOPでSELECT
最低なコーディングだが、その元凶はコボル病なのだ。
外部キーを横に２０個とか平気でやるよ奴ら。
で、
同じマスタを２０回ジョイン OR
フロントで行数×２０回LOOPでSELECT
最低なコーディングだが、その元凶はコボル病なのだ。
37 ：仕様書無しさん：2006/10/24(火) 22:23:02
>早い話がコボルすら読めない自称スーパープログラマが吠えるスレ
>でいいのか？
『RDBを理解できないコボラを見下すスレ』
>こんなこと書くと高確立で
高確じゃなくて確定。
コボラ乙
>でいいのか？
『RDBを理解できないコボラを見下すスレ』
>こんなこと書くと高確立で
高確じゃなくて確定。
コボラ乙
38 ：なぎさっち ◆Nagi/FmYMM ：2006/10/25(水) 10:55:15
>22
確立してどうする。
確立してどうする。
39 ：仕様書無しさん：2006/10/26(木) 02:45:03
横に256個以上カラムが定義できないと伝えると、烈火の如くRDB批判を繰り返すCOBOLer
256個以上の使用目的は、購入履歴001～購入履歴999まで作りたかっただけ。
256個以上の使用目的は、購入履歴001～購入履歴999まで作りたかっただけ。
>>38
勃立でどう？
勃立でどう？
>>39
そりゃRDBって言うよりaccessの制限じゃねーか？
DB2だと4000個くらいカラム定義できたと思うが。
もっとも4000項目もINSERT INTO ・・・・なんてSQL書きたくないが
そりゃRDBって言うよりaccessの制限じゃねーか？
DB2だと4000個くらいカラム定義できたと思うが。
もっとも4000項目もINSERT INTO ・・・・なんてSQL書きたくないが
42 ：仕様書無しさん：2006/10/26(木) 07:11:18
佐藤支ね
43 ：なぎさっち ◆Nagi/FmYMM ：2006/10/26(木) 13:06:06
さなぎっち(;´Д｀)ﾊｧﾊｧ
45 ：仕様書無しさん：2006/10/26(木) 22:14:51
>>39
縦推奨。
縦推奨。
それはまぎれも無く奴
47 ：334：2006/10/27(金) 00:53:35
Oracleで何で横長DBにするのか？
コボラの意見聞きたいわ。
なんで？
コボラの意見聞きたいわ。
なんで？
_')対応checkは存在したのですか。大丈夫だったですか。
Ｒらいと
>>334
そういう設計が正しいとされる世界の住人だったから。
そういう設計が正しいとされる世界の住人だったから。
ここまでに「正規化」という単語が出てきていない件
53 ：仕様書無しさん：2006/10/27(金) 21:20:22
>>52
性 器 化 で す か ？
性 器 化 で す か ？
>>52
リレーションという概念のない人にそんな言葉が通じるわけが
リレーションという概念のない人にそんな言葉が通じるわけが
55 ：仕様書無しさん：2006/11/06(月) 22:54:19
あげ
素で聞くが、縦とか横とか言っている意味から分からん。
>39の言ってることは分かる。そりゃバカなことだと分かる。
そんだけのことか？
>39の言ってることは分かる。そりゃバカなことだと分かる。
そんだけのことか？
57 ：仕様書無しさん：2006/11/08(水) 00:45:55
>>56
藻前がアフォーなだけ。
藻前がアフォーなだけ。
>>57
>39の例で言えば
1つのデータレコードに対して可変的に累積される項目データについて、
レコードに対して逐次項目増として対応するのが終わっている。
と取れるし同意するのだが、>1の書いていることは別のことに見えるんだよ。
>>58
オレの常識でも許せんよ。ド馬鹿か狂気を含む天才だな。それ。
>39の例で言えば
1つのデータレコードに対して可変的に累積される項目データについて、
レコードに対して逐次項目増として対応するのが終わっている。
と取れるし同意するのだが、>1の書いていることは別のことに見えるんだよ。
>>58
オレの常識でも許せんよ。ド馬鹿か狂気を含む天才だな。それ。
こぼらにテーブルを設計させると、必ずといっていいほど
FILLER
とかいう列がある
FILLER
とかいう列がある
>>62
>横長（XXコード１、XXコード２などを列で持たせる）に持つ
項目数が多かろうが少なかろうが、固定的か可変的かで全然意味が違う罠。
ケータイの着信履歴は最大30件～みたいな仕様だったら、横でいいだろ。
>横長（XXコード１、XXコード２などを列で持たせる）に持つ
項目数が多かろうが少なかろうが、固定的か可変的かで全然意味が違う罠。
ケータイの着信履歴は最大30件～みたいな仕様だったら、横でいいだろ。
横持ちとは関係ないけどフィールド名をF010～F220という風にするって
ワガママ言ってるんですがどうすればわかってくれるのか・・・
ちゃんと名前付けてほしいのと、増えたら間に入れるというのに危険を感じる。
当然ながら項目内容も横持ち＆なぞの多い複合キーだらけです。
ワガママ言ってるんですがどうすればわかってくれるのか・・・
ちゃんと名前付けてほしいのと、増えたら間に入れるというのに危険を感じる。
当然ながら項目内容も横持ち＆なぞの多い複合キーだらけです。
68 ：仕様書無しさん：2006/11/08(水) 22:14:42
カラムは1024で終わりかもしれんが
char(256)で、1カラム中を固定長フラグ項目で埋めるという技も併用してくるぞ
char(256)で、1カラム中を固定長フラグ項目で埋めるという技も併用してくるぞ
ワロタ
71 ：仕様書無しさん：2006/11/08(水) 22:48:21
まったく敵はいろんな手を使ってくるな・・・
そういう敵を打ち負かすにはスキルだけでなく理論武装もしとかないとな。
いかに相手のテーブル設計＆テーブル設計能力がダメか分からせてやらんといかん。
そういう敵を打ち負かすにはスキルだけでなく理論武装もしとかないとな。
いかに相手のテーブル設計＆テーブル設計能力がダメか分からせてやらんといかん。
73 ：仕様書無しさん：2006/11/09(木) 01:22:34
74 ：仕様書無しさん：2006/11/09(木) 02:42:18
こぼらは、先天的な脳疾患を抱えている可愛そうな人たち
だから許してやろうよ。
許せるか！あほコボラｗ
だから許してやろうよ。
許せるか！あほコボラｗ
75 ：仕様書無しさん：2006/11/09(木) 03:08:15
あ、そうか。だからなんでもまっすぐに配置したがるわけだ・・・。
>>63
新しい着信履歴をどの列に入れるかでアプリ側でごちゃごちゃ処理が入るし、
古い着信履歴を削除する場合にもいろいろやらなくちゃならん。
コボラーはそんな処理アプリでやって当然じゃんとか思ってるのかもしれんが。
新しい着信履歴をどの列に入れるかでアプリ側でごちゃごちゃ処理が入るし、
古い着信履歴を削除する場合にもいろいろやらなくちゃならん。
コボラーはそんな処理アプリでやって当然じゃんとか思ってるのかもしれんが。
78 ：仕様書無しさん：2006/11/09(木) 09:40:07
で、1行になんでもつめこんで、「速くなった。チューンした。」
とかいいだすんだよな。
とかいいだすんだよな。
クイズ 世界はケースバイケース
司会はIt's Me こと逸見政孝でお送りいたします。
司会はIt's Me こと逸見政孝でお送りいたします。
>>78
おまえかっ！！もっさりケータイをリリースしやがるのは！？
おまえかっ！！もっさりケータイをリリースしやがるのは！？
最近のケータイにはRDBが搭載されているのか・・・すごいな・・・
82 ：仕様書無しさん：2006/11/09(木) 22:25:17
ええことを考えた。
職場におるコボラにここのURL送れ！！
つーか、漏れは送ったった！！ ｗｗ
職場におるコボラにここのURL送れ！！
つーか、漏れは送ったった！！ ｗｗ
>>82
やつらはそのくらいじゃへこたれんよ。
やつらはそのくらいじゃへこたれんよ。
84 ：69式フリーPG ◆hND3Lufios ：2006/11/09(木) 23:05:48
おいらさ、引数指定レコードのフィールドをずらすストアドをPL/SQLで
書いてあげたことあるよ。用途は言うまでも無い。
書いてあげたことあるよ。用途は言うまでも無い。
>>84
それ公開しろよｗｗｗｗ
それ公開しろよｗｗｗｗ
86 ：仕様書無しさん：2006/11/09(木) 23:30:45
>>86
不覚にも保存した。
不覚にも保存した。
88 ：仕様書無しさん：2006/11/10(金) 00:57:12
89 ：仕様書無しさん：2006/11/10(金) 00:58:25
１０００万出してもいいからこの娘のマンコ舐めたいやつ手ぇ上げろ！！
>>89
娘じゃないかもよ
娘じゃないかもよ
91 ：仕様書無しさん：2006/11/10(金) 21:51:00
え？
どゆこと？
どゆこと？
遅無歩がついてる
93 ：仕様書無しさん：2006/11/11(土) 09:09:57
遅無歩？
ついててもええわ ｗ
ついててもええわ ｗ
94 ：仕様書無しさん：2006/11/12(日) 18:17:46
コボラって負け組？
ヤック デカルチャー
96 ：仕様書無しさん：2006/11/14(火) 20:40:35
コボラ＝NEET？
97 ：仕様書無しさん：2006/11/16(木) 03:23:12
設計がいまいちで縦長過ぎるのもまた大変だったりして。
SQL文が異様に長くなっちゃったりして。
ていうか、なった。
やっぱ view やストアドプロシジャ作るべきか・・・。
SQL文が異様に長くなっちゃったりして。
ていうか、なった。
やっぱ view やストアドプロシジャ作るべきか・・・。
>縦長過ぎる
レコード数が多いってことか？そんなことで「また大変だったりして」だとか、
「SQL文が異様に長くなっちゃったりして」にはならんと思うがｗ
レコード数が多いってことか？そんなことで「また大変だったりして」だとか、
「SQL文が異様に長くなっちゃったりして」にはならんと思うがｗ
今のトレンドは斜め
器用ダナw
103 ：仕様書無しさん：2006/11/16(木) 22:02:44
斜めってどういう状態？？？
>>98
「正規化し過ぎて」って事なんだろうな。
「正規化し過ぎて」って事なんだろうな。
結局逐次JOINするぐらいなら横長でもOKと言いたくなる
ま正規化のやり方が間違ってるわけだがな
誰だよこんなアホなDB設計した香具師は
ま正規化のやり方が間違ってるわけだがな
誰だよこんなアホなDB設計した香具師は
106 ：仕様書無しさん：2006/11/20(月) 22:46:06
DB（デブ）は横長にきまっとるがな。
とりあえず質量があればどうにでも整形できる。
108 ：仕様書無しさん：2006/11/23(木) 17:28:46
俺の先輩は、影でオッカーズと呼ばれ、恐れられている
大事な打ち合わせでは、呼ばないようにしている
大事な打ち合わせでは、呼ばないようにしている
109 ：仕様書無しさん：2006/11/23(木) 21:51:40
＞＞オッカーズ
どういう意味？
どういう意味？
110 ：仕様書無しさん：2006/11/23(木) 22:41:24
何でも夜のおかずにする人かな?
COBOLのOCCURSだろ？
いわゆる配列と思えばいい。
RDB定義体でOCCURS指定すると、第一正規形を崩すからな。
でも、OCCURSならまだいいよ。
MEMO1～MEMO999なんてカラム作られて、
MEMO675, MEMO675, MEMO676
なんてやられた日には殺意覚えるからな。
いわゆる配列と思えばいい。
RDB定義体でOCCURS指定すると、第一正規形を崩すからな。
でも、OCCURSならまだいいよ。
MEMO1～MEMO999なんてカラム作られて、
MEMO675, MEMO675, MEMO676
なんてやられた日には殺意覚えるからな。
112 ：仕様書無しさん：2006/11/23(木) 23:38:11
素朴な疑問。
何でコボラは横長にしたがるの？
何でコボラは横長にしたがるの？
113 ：仕様書無しさん：2006/11/23(木) 23:41:41
JOINなんて面倒じゃん。ビシッと一列に揃えたほうが気持ちいいし。
116 ：仕様書無しさん：2006/11/24(金) 20:57:05
周りの人は「縦持ち」「横持ち」ゆーとった
>>111
テストデータとしてこんなのを入れておくと良いだろう。
#!/usr/bin/perl
open(F, "| sqlplus -S /nolog") or die;
print F "conn hoge/fuga\n";
for ($i = 0; $i < 1000000; ++$i) {
print F 'insert into hoge (' . join(",\n", map {"MEMO$_"} 1..999) . ')'
. 'values (' . join(",\n", map {"'($i,$_) 馬鹿野郎!'"} 1..999) . ");\n";
}
print F "quit\n";
テストデータとしてこんなのを入れておくと良いだろう。
#!/usr/bin/perl
open(F, "| sqlplus -S /nolog") or die;
print F "conn hoge/fuga\n";
for ($i = 0; $i < 1000000; ++$i) {
print F 'insert into hoge (' . join(",\n", map {"MEMO$_"} 1..999) . ')'
. 'values (' . join(",\n", map {"'($i,$_) 馬鹿野郎!'"} 1..999) . ");\n";
}
print F "quit\n";
118 ：仕様書無しさん：2006/11/24(金) 22:56:10
連結って概念が無いんだろ。
122 ：仕様書無しさん：2006/11/24(金) 23:43:08
コボラをＩＴ業界から追放しよう。
どうすればいい？
どうすればいい？
124 ：仕様書無しさん：2006/11/25(土) 00:00:22
あ、なるほどね。
コボラは出世など考えずに、コボルだけやってればええってこった。
ＶＢ厨はまだ更正がきくかも。
コボラは出世など考えずに、コボルだけやってればええってこった。
ＶＢ厨はまだ更正がきくかも。
125 ：仕様書無しさん：2006/11/25(土) 00:18:17
＞ＶＢ厨はまだ更正がきくかも。
効くわけねーだろハゲ
効くわけねーだろハゲ
そういえば
「DBアクセスはテーブルのみヴューは使わない」
ってルールのフレームワーク作ってた会社があったな
JOINするという理由で難易度があがるという
「DBアクセスはテーブルのみヴューは使わない」
ってルールのフレームワーク作ってた会社があったな
JOINするという理由で難易度があがるという
128 ：仕様書無しさん：2006/11/25(土) 13:37:10
129 ：仕様書無しさん：2006/11/25(土) 19:10:23
MSが.NETをあきらめない限り、今後VB6での開発ではなく、C#同様にJavaもどきの
VB.NETを使うことになるので、VB厨はJava厨に吸収されていくのではないだろうか。
VB.NETを使うことになるので、VB厨はJava厨に吸収されていくのではないだろうか。
130 ：仕様書無しさん：2006/11/25(土) 19:29:46
コボラってテーブルを結合しないの？
>>130
テーブルを分ければ分けるほどプログラム作成工数が増大するらしいよ。
テーブルを分ければ分けるほどプログラム作成工数が増大するらしいよ。
>>132
ほんとかなあ。
ほんとかなあ。
ステップ数で単価を換算するCOBOLerにはいい儲け話じゃないか？
つか、再利用できるモジュールや関数を作る、作らないは
プログラマーの技量であってテーブルの分割とは関係ないな。
まー、VB厨も上から下まで一直線で同じ処理はコピペで済ます
芸風があるから、その辺りはどっちもどっちだな。
つか、再利用できるモジュールや関数を作る、作らないは
プログラマーの技量であってテーブルの分割とは関係ないな。
まー、VB厨も上から下まで一直線で同じ処理はコピペで済ます
芸風があるから、その辺りはどっちもどっちだな。
136 ：仕様書無しさん：2006/11/26(日) 20:03:03
>>132
コボル厨
コボル厨
>>136
コ、コボル厨ちゃうわ！
マジレスすると、自分のやり方が正しいと信じているコボラーSEを言い負かすには、
ある程度連中のやり方をしっとかないと。
「なぜ第一正規形にしないんですか」とか連中のしらん用語を使うのも効果有り。
コ、コボル厨ちゃうわ！
マジレスすると、自分のやり方が正しいと信じているコボラーSEを言い負かすには、
ある程度連中のやり方をしっとかないと。
「なぜ第一正規形にしないんですか」とか連中のしらん用語を使うのも効果有り。
>>137
コボラ語（コボルではなく）を学んでおくのは良いことだよな。
傾向と対策つか「こうきたらこう叩け」みたいな。
やつらの生態を知らないと、斜め上の発想に圧倒されてそのまま通す羽目になってしまう。
コボラ語（コボルではなく）を学んでおくのは良いことだよな。
傾向と対策つか「こうきたらこう叩け」みたいな。
やつらの生態を知らないと、斜め上の発想に圧倒されてそのまま通す羽目になってしまう。
>>138
彼らは完成されてるからね。我々より。斜め上の方向にｗ。なかなか手強い。
彼らは完成されてるからね。我々より。斜め上の方向にｗ。なかなか手強い。
迷うところがないというのは強いよね。
こちらが間違ってるんじゃないかという気になる。
こちらが間違ってるんじゃないかという気になる。
141 ：136：2006/11/27(月) 21:24:51
142 ：仕様書無しさん：2006/11/27(月) 21:29:53
>>138
そうやな。
『コボラの言いそうなこと』と
『それを黙らせる論理』が重要やな。
一応、年上だから立てておいて、
技術者としては終わってることをわからせる。
怒らせてもつまらんしな。
本当は、自分で勝手に限界を感じて、
ローソンにでも転職してくれるのが一番ええけど。
そうやな。
『コボラの言いそうなこと』と
『それを黙らせる論理』が重要やな。
一応、年上だから立てておいて、
技術者としては終わってることをわからせる。
怒らせてもつまらんしな。
本当は、自分で勝手に限界を感じて、
ローソンにでも転職してくれるのが一番ええけど。
こどもの顔を３日ぶりに見ることができた
ぼろぼろの状態の俺
るいせんが、ゆるむ
ぼろぼろの状態の俺
るいせんが、ゆるむ
こどもに頓着したい奴はこの業界に向かんぞ。
俺なんて、ほとんど子供と遊んだことない。
俺なんて、ほとんど子供と遊んだことない。
146 ：仕様書無しさん：2006/11/29(水) 01:50:04
>>144
せつない縦だなあ
せつない縦だなあ
なぜここで縦ｗ
149 ：仕様書無しさん：2006/11/29(水) 03:55:39
コボラとか自称ＳＥとかって、横長ＤＢが大好きだよな。
○○○○ＩＴソリューションの山本は、
１００フィールド越えのＤＢを設計しやがったし。
あと、別プロジェクトで、全てのテーブルを「マスタ」と称してることもあったな。
顧客マスタとか、商品マスタは良いとして、「売上マスタ」って何よ？
俺が、「売上テーブル」と言ったら、「売上マスタだ！！」と烈火の如く怒り出すし。
そういうセンスの欠片もない人間は、一刻も早くこの業界から足を洗って、
実家の酒屋を継ぐべし。
もしくは、過労死すべし。
○○○○ＩＴソリューションの山本は、
１００フィールド越えのＤＢを設計しやがったし。
あと、別プロジェクトで、全てのテーブルを「マスタ」と称してることもあったな。
顧客マスタとか、商品マスタは良いとして、「売上マスタ」って何よ？
俺が、「売上テーブル」と言ったら、「売上マスタだ！！」と烈火の如く怒り出すし。
そういうセンスの欠片もない人間は、一刻も早くこの業界から足を洗って、
実家の酒屋を継ぐべし。
もしくは、過労死すべし。
151 ：仕様書無しさん：2006/11/29(水) 09:49:38
>>150
俺としては、笑いごとじゃなかったのだが。
俺としては、笑いごとじゃなかったのだが。
マスタ = Jesus → 神
売り上げ → お客様 → 神
よって、
売り上げ = 神 = マスタ
ということではなかろうか?
とか思った徹夜明けの朝。
(もうすぐ昼だよ..)
売り上げ → お客様 → 神
よって、
売り上げ = 神 = マスタ
ということではなかろうか?
とか思った徹夜明けの朝。
(もうすぐ昼だよ..)
山本マスター
マエストロ
とお呼びください。
とお呼びください。
155 ：仕様書無しさん：2006/11/29(水) 15:28:02
ちなみに、ACCESSマクロで運用されていたシステムを、
SQL Serverにリプレイスするプロジェクトだった。
そのACCESSの中には、100個位の正規化されていないテーブルがあり、
処理用の「田中さん○○○○クエリ」やら、「山田さん○○○○クエリ」があった。
で、○○○○ＩＴソリューションの山本が聞取り調査をして、
必要なテーブルを集めてきたら、売上マスタを始めとして、全部○○マスタになってた。
取りあえず、山本君も、キャリア１５年を超えるのだから、マスタとはなんぞや位、
理解すべし。
もう、手遅れだろうけどね。
SQL Serverにリプレイスするプロジェクトだった。
そのACCESSの中には、100個位の正規化されていないテーブルがあり、
処理用の「田中さん○○○○クエリ」やら、「山田さん○○○○クエリ」があった。
で、○○○○ＩＴソリューションの山本が聞取り調査をして、
必要なテーブルを集めてきたら、売上マスタを始めとして、全部○○マスタになってた。
取りあえず、山本君も、キャリア１５年を超えるのだから、マスタとはなんぞや位、
理解すべし。
もう、手遅れだろうけどね。
マスターなら喫茶店に居ます。
157 ：仕様書無しさん：2006/11/29(水) 18:05:38
○○○○ＩＴソリューションのＳＥ（自称）の山本は、
テーブルに、インデックスを付けると全ての効率が上がると信じてる馬鹿者。
以前、SQLServerで一時テーブルを作成し、Excelファイルにエクスポートする
プログラム組んだら、「速度が遅いのはインデックス作成しないからだ。作成しろ」
とやかましく主張しやがった。
インデックス作成すると、インデックスの作成に時間がかかる上に、
新処理時にもインデックスを作成し直すから余計時間がかかると説明したが、
ヤツの頭では理解できなかったようだ。
現状のボトルネックになってるのがExcelの処理だと説明する為に、
ログ取ってやっと納得させた。
○○○○ＩＴソリューションには、馬鹿を再教育する制度はないのか！？
テーブルに、インデックスを付けると全ての効率が上がると信じてる馬鹿者。
以前、SQLServerで一時テーブルを作成し、Excelファイルにエクスポートする
プログラム組んだら、「速度が遅いのはインデックス作成しないからだ。作成しろ」
とやかましく主張しやがった。
インデックス作成すると、インデックスの作成に時間がかかる上に、
新処理時にもインデックスを作成し直すから余計時間がかかると説明したが、
ヤツの頭では理解できなかったようだ。
現状のボトルネックになってるのがExcelの処理だと説明する為に、
ログ取ってやっと納得させた。
○○○○ＩＴソリューションには、馬鹿を再教育する制度はないのか！？
VBプログラマは、ここ数年.NET Frameworkへの移行で四苦八苦してきた。
「静的型付言語」であるVisual Basic .NET（VB.NET）で従来のVBプログラマがまず叩き込まれるのは、「Option Strict On」である。
これによって、Visual Basicコンパイラが「正しい行い」をプログラマに強制する。
VBプログラマの苦痛は、VBが中途半端なニセモノプログラミング言語の汚名から解放され、真のプログラマが利用する言語へと進化するための痛みとして認識されている。
http://www.atmarkit.co.jp/fdotnet/special/pdc2005_02/pdc2005_02_01.html
@ITのVB関係の記事は、僻みか煽りか皮肉のどれかにしか見えない。
「静的型付言語」であるVisual Basic .NET（VB.NET）で従来のVBプログラマがまず叩き込まれるのは、「Option Strict On」である。
これによって、Visual Basicコンパイラが「正しい行い」をプログラマに強制する。
VBプログラマの苦痛は、VBが中途半端なニセモノプログラミング言語の汚名から解放され、真のプログラマが利用する言語へと進化するための痛みとして認識されている。
http://www.atmarkit.co.jp/fdotnet/special/pdc2005_02/pdc2005_02_01.html
@ITのVB関係の記事は、僻みか煽りか皮肉のどれかにしか見えない。
誤爆すまん。
160 ：仕様書無しさん：2006/11/30(木) 23:01:44
>>147
DB設計は横じゃなくて縦だっていうコボラへの啓蒙のためじゃね？
DB設計は横じゃなくて縦だっていうコボラへの啓蒙のためじゃね？
161 ：仕様書無しさん：2006/12/01(金) 00:25:53
.／ ＼
／＼ .＼
./ ＼ ＼
│ ＼ |
│ ⌒ ⌒ ＼ 丿 ／￣￣￣￣￣￣￣￣￣
.＼・ ・ ∨∨∨∨∨ ＜ ageちゃいますよ、課長。
С ∵∵∵/ ＼＿＿＿＿＿＿＿＿＿
/ っ）∵ /
.（＿＿ノ ∵/
＼＿＿ ＿＿ノ
丿 （
／＼ .＼
./ ＼ ＼
│ ＼ |
│ ⌒ ⌒ ＼ 丿 ／￣￣￣￣￣￣￣￣￣
.＼・ ・ ∨∨∨∨∨ ＜ ageちゃいますよ、課長。
С ∵∵∵/ ＼＿＿＿＿＿＿＿＿＿
/ っ）∵ /
.（＿＿ノ ∵/
＼＿＿ ＿＿ノ
丿 （
162 ：仕様書無しさん：2006/12/02(土) 03:34:39
そんなに横長でもないのだが、マスタを作らないでそのまま入れるのはいかがなものか、
というような表をこの前見た。
まあ、いわゆる、製品番号を付けないで製品名そのまんま入れるようなものかな。
縦長の素質あり。
というような表をこの前見た。
まあ、いわゆる、製品番号を付けないで製品名そのまんま入れるようなものかな。
縦長の素質あり。
163 ：仕様書無しさん：2006/12/02(土) 03:35:49
じゃない、横長の素質だ。w
164 ：仕様書無しさん：2006/12/02(土) 03:40:55
骨太、横長で何が悪い！
165 ：仕様書無しさん：2006/12/02(土) 03:50:39
美しいDB
166 ：仕様書無しさん：2006/12/02(土) 08:07:39
Oracleで予算管理システムのテーブルを設計しているとき、PLのコボラーが
売上実績１、売上実績２、～、売上実績６
みたいなカラムを延々と作るので、正規化しないと月別の集計がしにくいですよ
っつったら、
「画面も帳票も半期で閉じてるからいいんだよ！」
って烈火のごとく怒られた…
どこにでもいるんだね。RDBで横展開する年長者orz
売上実績１、売上実績２、～、売上実績６
みたいなカラムを延々と作るので、正規化しないと月別の集計がしにくいですよ
っつったら、
「画面も帳票も半期で閉じてるからいいんだよ！」
って烈火のごとく怒られた…
どこにでもいるんだね。RDBで横展開する年長者orz
167 ：仕様書無しさん：2006/12/02(土) 09:39:37
だから、オープン系プロジェクトにコボラーを参画させてはいけないことは、
ずいぶん前から常識なんだけどな
ついうっかりコボラーが紛れ込んできたら、線表の管理に専念させろ
（してるつもりにさせろ）
ずいぶん前から常識なんだけどな
ついうっかりコボラーが紛れ込んできたら、線表の管理に専念させろ
（してるつもりにさせろ）
168 ：仕様書無しさん：2006/12/02(土) 16:40:19
会社名は言えないが、坂東さんと黒柳さんがパーフェクトを狙う
あの番組のスポンサーの会社が受注したプロジェクトで、
たしか、「工場マスタ」とかいうテーブルの主キーである「工場コード」に、
「○○工場」「△△工場」「××工場」
という値がセットされてるのを見て、こいつら駄目だと思った。
一体、おたくらのグループはどういう社員教育してるんだ！？
自前でデータベースも作って販売してるんだろ。
まぁ、あのＤＢ、あんな程度の完成度だから、社員の質も知れてるってものかｗｗｗｗｗ
あの番組のスポンサーの会社が受注したプロジェクトで、
たしか、「工場マスタ」とかいうテーブルの主キーである「工場コード」に、
「○○工場」「△△工場」「××工場」
という値がセットされてるのを見て、こいつら駄目だと思った。
一体、おたくらのグループはどういう社員教育してるんだ！？
自前でデータベースも作って販売してるんだろ。
まぁ、あのＤＢ、あんな程度の完成度だから、社員の質も知れてるってものかｗｗｗｗｗ
169 ：仕様書無しさん：2006/12/02(土) 17:02:00
そういや、そのデータベースのメーカーでもある会社のプロジェクトで、
第１正規化もされてない設計がされてたなぁ。
どうせ、まともに設計する気ないなら、いっそのこと、
全テーブルを非正規化しちゃえ良いのに。
上の方の技師だの主任技師だのは、馬鹿だから、
そんな設計しても、メクラ印押すんじゃないかな。
第１正規化もされてない設計がされてたなぁ。
どうせ、まともに設計する気ないなら、いっそのこと、
全テーブルを非正規化しちゃえ良いのに。
上の方の技師だの主任技師だのは、馬鹿だから、
そんな設計しても、メクラ印押すんじゃないかな。
170 ：仕様書無しさん：2006/12/03(日) 00:33:37
新人でＪＡＶＡの研修したのに何故か汎用の現場に回された。
コボルきらいなんだけど。
コボルきらいなんだけど。
そーっすか
COBOLやる以上、OOPの考え方は一旦捨てざるを得ないな。
RDBについてはこぼらーがアホなだけだが。
RDBについてはこぼらーがアホなだけだが。
174 ：仕様書無しさん：2006/12/03(日) 12:00:24
そもそもコボルやってる奴は頭が悪い
175 ：仕様書無しさん：2006/12/03(日) 15:45:03
MOVE MOVEうざいんだよ。コボルは。
何がCOPY句だ。うざいんだよ。
何がCOPY句だ。うざいんだよ。
COBOLの構造体をそのまま文字列整形する仕組みは好きだなと思った。
C++でもprivateな文字列フィールドを埋め込めばいいと考えればそれまでだが。
C++でもprivateな文字列フィールドを埋め込めばいいと考えればそれまでだが。
177 ：仕様書無しさん：2006/12/03(日) 20:10:54
今は、Ｃ＃の時代
いいじゃん、横長定義くらいで済んでるなら。
俺の悩みはなー、引き継いでるDBのカラムが1列だけしかないってことだ。
その1列が、何桁目からN桁が項目Aで、次のM桁が項目Bで……。
誰だ、こんなの出荷したバカは～!
俺の悩みはなー、引き継いでるDBのカラムが1列だけしかないってことだ。
その1列が、何桁目からN桁が項目Aで、次のM桁が項目Bで……。
誰だ、こんなの出荷したバカは～!
179 ：仕様書無しさん：2006/12/03(日) 23:30:54
>>166
コボラ由来のＤＢにそういうのよく見るよな。
このままやっていると頭がおかしくなるので、
俺はついこんなことしまう。
SELECT ・・・ ,'1' AS 実績月 ,売上実績１ AS 売上実績
FROM 予算管理テーブル
UNION
SELECT ・・・ ,'2' AS 実績月 ,売上実績２ AS 売上実績
FROM 予算管理テーブル
UNION
(以下略)
>>178
あまりの潔さに大爆笑（藁）
コボラ由来のＤＢにそういうのよく見るよな。
このままやっていると頭がおかしくなるので、
俺はついこんなことしまう。
SELECT ・・・ ,'1' AS 実績月 ,売上実績１ AS 売上実績
FROM 予算管理テーブル
UNION
SELECT ・・・ ,'2' AS 実績月 ,売上実績２ AS 売上実績
FROM 予算管理テーブル
UNION
(以下略)
>>178
あまりの潔さに大爆笑（藁）
>>166 >>178
そういうのって、多分アンロードしてファイルで扱うことが前提なのだろうな。
正規化してると逆に扱いにくいから。
でも、>>178みたいなのは最初からDBなんて使うなよってレベルだな。
そういうのって、多分アンロードしてファイルで扱うことが前提なのだろうな。
正規化してると逆に扱いにくいから。
でも、>>178みたいなのは最初からDBなんて使うなよってレベルだな。
181 ：２９１：2006/12/03(日) 23:51:28
>>180
さらに、客である○○○○ＩＴソリューションの山本がそういう仕様を出してきた時に、
うちの会社の長居主任の作成した仕様書に、
○○の処理が終わったら、××フィールド（数値）をと４を足す。
○○の処理が失敗したら、××フィールド（数値）に２を引く。
みたいなことが書いてあった。
よくよく考えると、ある桁のビットのセットやリセットのことだった。
コボラーにもなれない馬鹿ＳＥも痛々しいが、
オラクル厨でマスク処理とか知らない主任（現在課長）も死んでほしいと思った。
さらに、客である○○○○ＩＴソリューションの山本がそういう仕様を出してきた時に、
うちの会社の長居主任の作成した仕様書に、
○○の処理が終わったら、××フィールド（数値）をと４を足す。
○○の処理が失敗したら、××フィールド（数値）に２を引く。
みたいなことが書いてあった。
よくよく考えると、ある桁のビットのセットやリセットのことだった。
コボラーにもなれない馬鹿ＳＥも痛々しいが、
オラクル厨でマスク処理とか知らない主任（現在課長）も死んでほしいと思った。
理由は判ってて、昔オフコン時代に動いていたのをPC+Windowsにリプレースする
際に、なーんも考えずにDATA DIVISIONをそのままベタで置き換えたから。
仕方ないから、後から別にsubstrが山と入っているviewを追加してしのぐという
パフォーマンス最悪なシロモノ。
ちなみに、当然のごとく文字コードはJA16SJIS厳守。位置がずれるから…。
こんなのでも世間では一式1千万円超のシステムとして売られてるってんだから、
恐ろしい話だ。
際に、なーんも考えずにDATA DIVISIONをそのままベタで置き換えたから。
仕方ないから、後から別にsubstrが山と入っているviewを追加してしのぐという
パフォーマンス最悪なシロモノ。
ちなみに、当然のごとく文字コードはJA16SJIS厳守。位置がずれるから…。
こんなのでも世間では一式1千万円超のシステムとして売られてるってんだから、
恐ろしい話だ。
>>181
マスク処理が分からない人は意外にに多いよ。
バイナリフラグなのに８ビット平気で使うし。
まあいいけどね。INPUTとOUTPUTを必ずペアにしなければ
ならないことを完全に忘れてるUI設計をしなければ。
データが突然ボウフラのように沸いてくるような設計だけは
ホント勘弁だわ。
マスク処理が分からない人は意外にに多いよ。
バイナリフラグなのに８ビット平気で使うし。
まあいいけどね。INPUTとOUTPUTを必ずペアにしなければ
ならないことを完全に忘れてるUI設計をしなければ。
データが突然ボウフラのように沸いてくるような設計だけは
ホント勘弁だわ。
184 ：仕様書無しさん：2006/12/04(月) 02:14:23
>>183
まぁ、マスク処理分からないなら、分からないで良いから、
「○○ビット目をセットすること」
と書きゃいいんだ。
分からんなら、早々に人に聞けばいいのに、聞かないからこういうことになる。
それにしても、「マスク処理を知らないが、ソフト会社の課長」って笑えるよなｗ
まぁ、マスク処理分からないなら、分からないで良いから、
「○○ビット目をセットすること」
と書きゃいいんだ。
分からんなら、早々に人に聞けばいいのに、聞かないからこういうことになる。
それにしても、「マスク処理を知らないが、ソフト会社の課長」って笑えるよなｗ
185 ：仕様書無しさん：2006/12/04(月) 06:00:00
>>182
もし、COBOLで読み書きしていたデータをRDB化しろ・・・という
業務命令を受けたら、「正規化」という言葉が通じない職場なら
俺でもそうするかもしれないな。
世知辛い話だがとして後先考えても得するのが自分じゃなければ
むしろ、余分な工数かけるなと怒られるのが関の山だから。
COBOLerがあいつが勝手にいじったとちくられるはロクな事ないし。
もちろん自分が面倒みなきゃいけないことがわかっているなら
きちんと正規化して後々自分が困らないようにするけどね。
そうやって、横長RDBが増殖していくんだろうな。
もし、COBOLで読み書きしていたデータをRDB化しろ・・・という
業務命令を受けたら、「正規化」という言葉が通じない職場なら
俺でもそうするかもしれないな。
世知辛い話だがとして後先考えても得するのが自分じゃなければ
むしろ、余分な工数かけるなと怒られるのが関の山だから。
COBOLerがあいつが勝手にいじったとちくられるはロクな事ないし。
もちろん自分が面倒みなきゃいけないことがわかっているなら
きちんと正規化して後々自分が困らないようにするけどね。
そうやって、横長RDBが増殖していくんだろうな。
186 ：○○○○ＩＴソリューションの山本：2006/12/04(月) 22:06:40
コレ以降は
『コボラが～』
じゃなくて、すべて
『○○○○ＩＴソリューションの山本が～』
にしようぜ！！
『コボラが～』
じゃなくて、すべて
『○○○○ＩＴソリューションの山本が～』
にしようぜ！！
187 ：仕様書無しさん：2006/12/04(月) 22:09:33
188 ：仕様書無しさん：2006/12/04(月) 22:14:58
スレタイ変更
『○○○○ＩＴソリューションの山本』は横長ＤＢがお好き
『○○○○ＩＴソリューションの山本』は横長ＤＢがお好き
あのさ、東芝ITソリューションつっても合併繰り返して従業員多いんだからさ、
お前の頭の中には特定の一人かもしれんが、中には役員クラスもいるかもしれん
のに、そんなに名前連呼してりゃどうなっても知らんぞ?
お前の頭の中には特定の一人かもしれんが、中には役員クラスもいるかもしれん
のに、そんなに名前連呼してりゃどうなっても知らんぞ?
誰か東芝と言いました？
実際にはこの手の伏字もどきは気休めにもならないし。
TISのスレなかったっけ？
193 ：仕様書無しさん：2006/12/05(火) 00:10:59
194 ：仕様書無しさん：2006/12/05(火) 00:13:21
195 ：仕様書無しさん：2006/12/05(火) 00:16:49
196 ：仕様書無しさん：2006/12/05(火) 00:22:24
○○○○ＩＴソリューションの山本は、今年で入社１５年目の大ベテラン
彼のスキルを列挙します。
ＤＢ設計：独特な定義手法
もしかして、正規化って言葉も知らないのか？と思う君は甘い。
それこそ、「ＩＴソリューション」
プログラム設計：２１世紀の手法「ポンチ絵法」を確立。
スピーディーな設計と、情報漏洩対策もバッチリです。
出世の戦略：信長方式です。
現在は、家督争い中のようで、「うつけ者」を装っています。
能ある鷹は爪隠すといいますが、仕事や雑談でも、才能を完璧に隠しとおします。
いつ、才能を見せてくれるのか、楽しみです。
彼のスキルを列挙します。
ＤＢ設計：独特な定義手法
もしかして、正規化って言葉も知らないのか？と思う君は甘い。
それこそ、「ＩＴソリューション」
プログラム設計：２１世紀の手法「ポンチ絵法」を確立。
スピーディーな設計と、情報漏洩対策もバッチリです。
出世の戦略：信長方式です。
現在は、家督争い中のようで、「うつけ者」を装っています。
能ある鷹は爪隠すといいますが、仕事や雑談でも、才能を完璧に隠しとおします。
いつ、才能を見せてくれるのか、楽しみです。
197 ：仕様書無しさん：2006/12/05(火) 00:26:51
198 ：仕様書無しさん：2006/12/05(火) 00:29:19
199 ：仕様書無しさん：2006/12/05(火) 00:42:02
富士電機？
201 ：仕様書無しさん：2006/12/05(火) 07:45:35
>>200
君、具体的な人物に心当たりあるのかい？
君、具体的な人物に心当たりあるのかい？
202 ：仕様書無しさん：2006/12/05(火) 08:53:55
create table文を作成するperlスクリプトがあったり。
なんか、日曜の夜中あたりからコボ厨よりレベルの低いガキが沸いてるな。
頭の固いコボラも困るが、社会常識の無いガキはマジで仕事に使えねぇ。
名前を出してる粘着さんなんか、クビにしたら去り際にリポジトリ破壊とか
していきそうだね。
頭の固いコボラも困るが、社会常識の無いガキはマジで仕事に使えねぇ。
名前を出してる粘着さんなんか、クビにしたら去り際にリポジトリ破壊とか
していきそうだね。
perl -e 'print "create table hoge (" . join(",",map{"A$_ char(100)"}1..1000) . ");\n";' | sqlplus hoge/fuga
205 ：仕様書無しさん：2006/12/05(火) 17:31:23
コボラの作ったＤＢの話ならしたいが、
○○さんの話は聞きたくない。
○○さんの話は聞きたくない。
206 ：仕様書無しさん：2006/12/05(火) 20:57:01
http://b.hatena.ne.jp/entry/http://www.rubyist.net/~matz/20061115.html
世の中の半数以上のプログラマはCOBOLに投入され、
メンテナンスだけではなくて新規の開発も行われています。
世の中の半数以上のプログラマはCOBOLに投入され、
メンテナンスだけではなくて新規の開発も行われています。
横長DBもそうだが、
画面設計も相当終わってるぞ。
モードを入力してから、（1:新規、2:修正、9:削除 など）
コードを入力して編集とか。
RDBだけでなくGUIも台無し。
画面設計も相当終わってるぞ。
モードを入力してから、（1:新規、2:修正、9:削除 など）
コードを入力して編集とか。
RDBだけでなくGUIも台無し。
そういやエンターキーでカーソル移動ってまだやってるとこあるんだろうか？
F1押下でプリントアウトする
>>211-212
顧客の要望として「そうせよ」と言うのはよくあることでしょうね。
顧客の要望として「そうせよ」と言うのはよくあることでしょうね。
せめて、現行の動作も持たせつつ、
ドロップダウンリストとかにして欲しいな。
１，２，９以外を入力したら、
「（×）正しく入力してください[OK]」
とか出すらしい。
あー、ばかばかしい。
ドロップダウンリストとかにして欲しいな。
１，２，９以外を入力したら、
「（×）正しく入力してください[OK]」
とか出すらしい。
あー、ばかばかしい。
イレギュラーを作り出してる。
>>208
まぁ、それは一行で済むから許してやろうぜ。
まぁ、それは一行で済むから許してやろうぜ。
いや、許さん。
＿
こぼらはﾀﾋんでください。
こぼらはﾀﾋんでください。
＿
こぼらはﾀﾋんでください。
こぼらはﾀﾋんでください。
＿
こぼらはﾀﾋんでください。
こぼらはﾀﾋんでください。
『テーブルを性器化しないコボラーを叩くスレ』
いやだ
ていうか、TABでええやん。
エェー、嫌だぁ。と入力専用女子に一蹴されますた。
デフォルトボタンの機能が「次の入力欄にフォーカスを移動すること」じゃ駄目かな？
標準の動作として、ダイアログでEnterしたらOKとかで
Escしたらキャンセルとかになるっていうのがあるんだよな。
OKにカーソルあるときにEnter押したら、次に飛ぶのか閉じるのか？
あるいは複数行入力があったとして
その上でEnterしたら改行入力？次に飛ぶ？
知ってる中で一番けったいな構造は介護保険の「単位数マスタ」かな。
データ構造も繰り返しばかりだし、過去にさかのぼって修正ってのをやらないから
日付によって項目の解釈を変えないといけなかったりする。
Escしたらキャンセルとかになるっていうのがあるんだよな。
OKにカーソルあるときにEnter押したら、次に飛ぶのか閉じるのか？
あるいは複数行入力があったとして
その上でEnterしたら改行入力？次に飛ぶ？
知ってる中で一番けったいな構造は介護保険の「単位数マスタ」かな。
データ構造も繰り返しばかりだし、過去にさかのぼって修正ってのをやらないから
日付によって項目の解釈を変えないといけなかったりする。
230 ：仕様書無しさん：2006/12/15(金) 20:51:57
コボラは自分が亜フォであることをまず認めよう。
話はそれから。
１０コ下の後輩に頭下げてRDB、GUIを真鍋。
話はそれから。
１０コ下の後輩に頭下げてRDB、GUIを真鍋。
231 ：仕様書無しさん：2006/12/15(金) 20:52:53
あるいは、出世して現場離れろ。
コボラは、現場にいると害になる。
コボラは、現場にいると害になる。
腐れ上司の一言スレに登場しそうだ w
233 ：仕様書無しさん：2006/12/15(金) 21:46:26
単純に『コボラを叩くスレ』
テンキーの傍にTABキーとShift+TABキーのペアがあればいいのにな。
TABでフォーカス移動ってのもどうかとは思うんだよな。Winのお作法とはいえ。
今までﾕｻﾞに教えてあげて知ってたヤツは皆無。
んで、タブーオーダーという概念も理解してないし。
Enter押したらデフォルトボタンが押されてダイアログが閉じられて発狂パターンも多い。
Enter=入力終了＆次の項目へ
Tab=デフォルトボタン押下
ってルールでもいいかも知れんと思ってしまうオレガイル
今までﾕｻﾞに教えてあげて知ってたヤツは皆無。
んで、タブーオーダーという概念も理解してないし。
Enter押したらデフォルトボタンが押されてダイアログが閉じられて発狂パターンも多い。
Enter=入力終了＆次の項目へ
Tab=デフォルトボタン押下
ってルールでもいいかも知れんと思ってしまうオレガイル
TABで移動はS/390の頃からあったんじゃないのか・・・？
漏れがAS/400触った頃には既にあったので、Winの作法でも
なんでもなくて、Winが汎用機からパクったと思うのだが。
あと業務用のテンキーパッドはちゃんと打ちやすい位置にTABとバックTABがある。
そして[ENTER]と[実行]は別物なので、右手のみで自由に画面をカーソル駆け巡り
画面遷移が出来る。
漏れがAS/400触った頃には既にあったので、Winの作法でも
なんでもなくて、Winが汎用機からパクったと思うのだが。
あと業務用のテンキーパッドはちゃんと打ちやすい位置にTABとバックTABがある。
そして[ENTER]と[実行]は別物なので、右手のみで自由に画面をカーソル駆け巡り
画面遷移が出来る。
Winのお作法かどうかはさておき、一般ﾕｻﾞは知らんことが多いよ。
コボラの辞書にGUIという文字はない
239 ：仕様書無しさん：2006/12/16(土) 23:04:34
コボラは貴所イ。
「技術職なんだからこのくらい常識だ！」という言う片方では
（自分たちが技術者との知らないことは）「そんなの普通の人に解るわけないじゃないか！」と
平然と言い放てるようなスバラシイ精神をもっているのがｺﾎﾞﾗ。
（自分たちが技術者との知らないことは）「そんなの普通の人に解るわけないじゃないか！」と
平然と言い放てるようなスバラシイ精神をもっているのがｺﾎﾞﾗ。
>>240
この間、日立○作所の人間にソレ言われたよ。
そっちのミスでバッチ処理を走らせる順番間違えたので、
その報告を聞いた漏れが「間違えたジョブのプロセスを停止かKILLすれば？」って
言ったら「そんなの普通の人に出来るわけない」と逆ギレされますた。
言っている意味が解らんかったら少しは自分で調べてから返答しろよ。
この間、日立○作所の人間にソレ言われたよ。
そっちのミスでバッチ処理を走らせる順番間違えたので、
その報告を聞いた漏れが「間違えたジョブのプロセスを停止かKILLすれば？」って
言ったら「そんなの普通の人に出来るわけない」と逆ギレされますた。
言っている意味が解らんかったら少しは自分で調べてから返答しろよ。
243 ：仕様書無しさん：2006/12/22(金) 21:29:27
244 ：仕様書無しさん：2007/01/06(土) 18:22:46
あげ
暴力団アゲ
去年、コボラーのオッサンが作ったプログラムを
javaに書き換えるプロジェクトに参加させてもらったが
ＤＢが全く正規化されていなかった。orz
まぁ、ある程度は覚悟してたからいいんだが、
そのオッサンがＰＬでプロジェクトが崩壊した
あっ、俺は勿論バックレ
javaに書き換えるプロジェクトに参加させてもらったが
ＤＢが全く正規化されていなかった。orz
まぁ、ある程度は覚悟してたからいいんだが、
そのオッサンがＰＬでプロジェクトが崩壊した
あっ、俺は勿論バックレ
247 ：仕様書無しさん：2007/01/29(月) 01:29:54
そのまま移植しようとするからバカなんだよ。コボラは。
248 ：仕様書無しさん：2007/01/29(月) 01:32:02
ばっくれる前にその親父叩き潰せよ。
データウェハウスの案件で、
「じゃ、DBみせてください。」と言ったら、
出てきたのがCOBOLのコピー句を印刷したものだった。orz
「じゃ、DBみせてください。」と言ったら、
出てきたのがCOBOLのコピー句を印刷したものだった。orz
>>250
いや、「デーベー」。ｗｗｗ
いや、「デーベー」。ｗｗｗ
代田橋
253 ：仕様書無しさん：2007/02/10(土) 20:51:08
新人でコボル現場２年目なんだけど（本当はオープン希望だった）
俺の上司に教わったことが常識だと思ってたが不安に感じてきたな。
コボラの上司たちはコボルができれば仕事はなくならないから
見たいな事や、オープン系は糞って言ってたけど
実際どうなの？
俺の上司に教わったことが常識だと思ってたが不安に感じてきたな。
コボラの上司たちはコボルができれば仕事はなくならないから
見たいな事や、オープン系は糞って言ってたけど
実際どうなの？
>>253
かわいそうだけど、君はもう、、
かわいそうだけど、君はもう、、
>コボラの上司たちはコボルができれば仕事はなくならないから
>見たいな事や、オープン系は糞って言ってたけど
・・・・・という話が本当ならば、COBOLの教育がもっと頻繁に行われているはずなのだけど・・・・・ね。
>見たいな事や、オープン系は糞って言ってたけど
・・・・・という話が本当ならば、COBOLの教育がもっと頻繁に行われているはずなのだけど・・・・・ね。
257 ：仕様書無しさん：2007/02/12(月) 00:58:38
まぁ、正規化は常に性能とトレードオフ。
どうせ一トランザクションで舐めることになるデータは一レコードに持たせておいた方が、CPU使用量（LockにかかるCPUとかも含めて）とか、I/OWAIT等々の観点で有利。
と言ってみるテスト。
どうせ一トランザクションで舐めることになるデータは一レコードに持たせておいた方が、CPU使用量（LockにかかるCPUとかも含めて）とか、I/OWAIT等々の観点で有利。
と言ってみるテスト。
259 ：仕様書無しさん：2007/02/12(月) 02:35:30
>>257
昔なら、非正規化の理由としてそれもあったかもしれんが、
現在のように機能強化や変更がたびたび起こる様な状況では
開発速度、追加した機能のパフォーマンスなどを含めた、
トータルの性能では正規化した方に分があると思う。
昔なら、非正規化の理由としてそれもあったかもしれんが、
現在のように機能強化や変更がたびたび起こる様な状況では
開発速度、追加した機能のパフォーマンスなどを含めた、
トータルの性能では正規化した方に分があると思う。
担当1～担当4とかあって、開始時間と終了時間を含んだレコードがあるとする。
更新のたびに、日付と担当者コードで重複チェックしたり、
担当者ごとに日数集計したりするっていうのは
非正規化状態ではまともに読めるコードは書けなかった。
書いても遅かったし。
正規化を検討して、その結果やめるのはいいんだが
検討もせずに非正規化でほっておくのはなぁ・・・
更新のたびに、日付と担当者コードで重複チェックしたり、
担当者ごとに日数集計したりするっていうのは
非正規化状態ではまともに読めるコードは書けなかった。
書いても遅かったし。
正規化を検討して、その結果やめるのはいいんだが
検討もせずに非正規化でほっておくのはなぁ・・・
デットロック発生！
264 ：仕様書無しさん：2007/02/14(水) 00:43:26
265 ：仕様書無しさん：2007/02/14(水) 00:47:12
266 ：仕様書無しさん：2007/02/14(水) 00:47:27
267 ：仕様書無しさん：2007/02/14(水) 00:48:29
268 ：仕様書無しさん：2007/02/14(水) 00:49:22
みすたーーーーーーーーー
FROM-Aだ。
買いに行くのは漏れか orz
FROM-Aだ。
買いに行くのは漏れか orz
269 ：仕様書無しさん：2007/02/14(水) 00:56:08
コボラが作ったテーブルで
横長に250ほどカラムがあるんですが・・・
ざっくりリレーショナルに作っていけば100以下になりそうです
設計者を殺したいんですが構わないでしょうか？
横長に250ほどカラムがあるんですが・・・
ざっくりリレーショナルに作っていけば100以下になりそうです
設計者を殺したいんですが構わないでしょうか？
250ならギリセーフ
>>270
な、わけが。
な、わけが。
273 ：仕様書無しさん：2007/02/14(水) 02:25:35
>>272
コボラとはPg業界に巣食うシロアリ的存在なのですね？
コボラとはPg業界に巣食うシロアリ的存在なのですね？
>>273
それは、コンピュータは電気で動いてますよね？くらい間抜けな話
それは、コンピュータは電気で動いてますよね？くらい間抜けな話
>>272
コボラはデータが固定長でないと気に入らないからな。
コボラはデータが固定長でないと気に入らないからな。
276 ：仕様書無しさん：2007/02/14(水) 04:44:24
なんか最近、コボラ的行動にいちいち腹立てる香具師を見るのも楽しくなってきた
もちろん自分に被害の無い範囲で
もちろん自分に被害の無い範囲で
糞コボラは新規設計のテーブルになぜかフィラー512バイトを最初から付けてくる...。
279 ：仕様書無しさん：2007/02/14(水) 21:14:11
後から列を追加するコマンドとかあるみたいだけど、ああいうのは使わないのが普通なのかな?
281 ：仕様書無しさん：2007/02/14(水) 22:07:39
>>279
FILLERをつけることによってタプルサイズをブロックサイズと同一にし、
それによりロックの競合やロックエスカレーションを避けることを意図している設計だ。
俺様は一流なので、ポンコツDBMS上で実装する時にそういう意図でやることはあるが、
なんてことはコボラーが思いつくはずはない。
つまり、野生の勘だけでそれを実装できるコボラーは、
ある意味では俺様より偉い存在だといえる。
FILLERをつけることによってタプルサイズをブロックサイズと同一にし、
それによりロックの競合やロックエスカレーションを避けることを意図している設計だ。
俺様は一流なので、ポンコツDBMS上で実装する時にそういう意図でやることはあるが、
なんてことはコボラーが思いつくはずはない。
つまり、野生の勘だけでそれを実装できるコボラーは、
ある意味では俺様より偉い存在だといえる。
282 ：仕様書無しさん：2007/02/14(水) 22:46:57
283 ：仕様書無しさん：2007/02/14(水) 22:50:15
今カスタマイズでやってる仕事がまさにコレだな。
テーブルにフィールドを追加するだけだから簡単だと思ったら
最大フィールド数を超えたとかで泣きそうになった。
テーブルにフィールドを追加するだけだから簡単だと思ったら
最大フィールド数を超えたとかで泣きそうになった。
SELECT * ～で取ってきては１件読んでチェックして、１件読んでチェックして・・・・・・・
挙げ句に「何で遅いのかさっぱり解りません！コレだからOpen系はクソだ！わけわからん！」
なんて逆ギレして返品されたこぼらを最近見た・・・・・
挙げ句に「何で遅いのかさっぱり解りません！コレだからOpen系はクソだ！わけわからん！」
なんて逆ギレして返品されたこぼらを最近見た・・・・・
配列もあるし，RecordSetじゃないけどPL/SQLのCursorみたいな機能もある．
ただCOBOLの処理が根本的に違うのは基本的にテーブル／ファイルを
全件操作するのが前提で物事を考えること．
顧客データをSQLでSELECT * FROM USER_M WHERE STATUS = 1
とか抽出するんじゃなくて，
SELECT * FROM USER_M で全件取得して，カーソルで回す．
昔のデータ件数と，汎用機の化け物じみたマシンスペックではそれも可能だったんだけど，
RDBとかオープン系とかはその辺の限界を打破するために出てきたようなもんだから，
いわゆるパラダイムシフトですね．
地動説と天動説の違いみたいなもんですよ．
ちなみに私が知ってるのは主流のCOBOL85より一つ？古いCOBOL74規格なんで，
最近は違うのかもしれませんが．
ただCOBOLの処理が根本的に違うのは基本的にテーブル／ファイルを
全件操作するのが前提で物事を考えること．
顧客データをSQLでSELECT * FROM USER_M WHERE STATUS = 1
とか抽出するんじゃなくて，
SELECT * FROM USER_M で全件取得して，カーソルで回す．
昔のデータ件数と，汎用機の化け物じみたマシンスペックではそれも可能だったんだけど，
RDBとかオープン系とかはその辺の限界を打破するために出てきたようなもんだから，
いわゆるパラダイムシフトですね．
地動説と天動説の違いみたいなもんですよ．
ちなみに私が知ってるのは主流のCOBOL85より一つ？古いCOBOL74規格なんで，
最近は違うのかもしれませんが．
確かに、ちょっとはRDB知っているボコラはカーソル大好きだな。
コボラがつくったみたいなフレームワークで、DBアクセスの基本が1テーブルのみで、JOINが増えると開発難易度があがるというアホなのがある
使用するテーブルなどは別途宣言が必要で、VIEWを使う事は想定外
使用するテーブルなどは別途宣言が必要で、VIEWを使う事は想定外
RDBにもカーソルがあるわけだが・・・
>>288
それはヴビ厨にも言えるな。
それはヴビ厨にも言えるな。
コボラＤＢで悪戦苦闘している人を今日みた。
どうやら主キーが10桁くらいの文字型になっている様子。
そのテーブルの前4桁くらいを外部キーとして別テーブルとJoinしたり、
大量UPDATEをする処理が重くてしょうがないそうだ。
どうやら主キーが10桁くらいの文字型になっている様子。
そのテーブルの前4桁くらいを外部キーとして別テーブルとJoinしたり、
大量UPDATEをする処理が重くてしょうがないそうだ。
いや、それは、オマエの文章もバグってる。
デバッグよろ。想像で。
おk
本来は
char(4)
char(6)
の2カラムでユニークにするべき所を
char(10)
の1カラムにしているってことだな
char(4)
char(6)
の2カラムでユニークにするべき所を
char(10)
の1カラムにしているってことだな
そう。そしてそのchar(10)がそのテーブルの主キーになっているらしい。
で、他テーブルとのJOINは
substr( char(10)のカラム ,1,4 )=他テーブルのキー
とかだな
substr( char(10)のカラム ,1,4 )=他テーブルのキー
とかだな
同じUPDATE処理のはずが、substr( char(10)のカラム ,1,4 )の値によってUPDATEするカラムとか、カラム中のアップデートする桁が変わったりとかも
>>302
ボコラＤＢ（汎用機のファイルをそのままテーブルにしたようなもの）の場合、
char(6)の方の先頭一文字目でUPDATE対象が変わったりすることが多い。
契約番号,入金日,自動継続,・・・・
A001P-1234,20070228,1,・・・・
みたいな感じで、
契約番号は本来
substr(契約番号,1,4) as 得意先コード
substr(契約番号,5,1) as 契約種別
substr(契約番号,7,4) as 得意先別シーケンシャルNo
だったりする。
ボコラＤＢ（汎用機のファイルをそのままテーブルにしたようなもの）の場合、
char(6)の方の先頭一文字目でUPDATE対象が変わったりすることが多い。
契約番号,入金日,自動継続,・・・・
A001P-1234,20070228,1,・・・・
みたいな感じで、
契約番号は本来
substr(契約番号,1,4) as 得意先コード
substr(契約番号,5,1) as 契約種別
substr(契約番号,7,4) as 得意先別シーケンシャルNo
だったりする。
こうだった orz...
契約番号,入金日１,,入金日２・・・,入金日１２,自動継続,・・・
契約番号,入金日１,,入金日２・・・,入金日１２,自動継続,・・・
入金日１は4月な
306 ：仕様書無しさん：2007/02/19(月) 20:59:38
お前２ちゃんねるに書き込みしただろ？って上司に言われた・・・
COBOLerの思考回路はどこいっても大差ないから、
書き込みで特定はされないと思うけど。
書き込みで特定はされないと思うけど。
308 ：仕様書無しさん：2007/02/19(月) 22:45:01
しかたがないよ。
我々とコボラは職業が違うのだから。
我々とコボラは職業が違うのだから。
コボラは現代における「本物のプログラマ」です。
310 ：仕様書無しさん：2007/02/20(火) 14:52:58
JOINしたら怒られた
SELCT * FROM テーブル名で関連テーブル全部開いて
ぐるぐるカーソル回して探すのが正しいやり方らしい
SELCT * FROM テーブル名で関連テーブル全部開いて
ぐるぐるカーソル回して探すのが正しいやり方らしい
辞めたら？無能な連中と一緒にいてもいいことないよ。
そういう事をのたまうアフォがいる会社を晒せばいいんじゃないか？
たとえば某日○製作所とかサ
たとえば某日○製作所とかサ
314 ：仕様書無しさん：2007/02/21(水) 00:40:50
うん。指導担当に恵まれてたから正しくない事を理解できた。
その人は社内では新参SEで業務知識が弱いのとコボラ相手に疲れて転職したけどな
おいらも4年ちょいいてそろそろ潮時かなって思って辞めた。
でも職業PGとしての師匠は最初の指導担当の先輩だと思ってる。
コボラ達と意思疎通が困難な中で、自分が新人の頃には先輩に世話になった
今度はおいらの番だって指導にあたってくれたおかげで今がある。
その人は社内では新参SEで業務知識が弱いのとコボラ相手に疲れて転職したけどな
おいらも4年ちょいいてそろそろ潮時かなって思って辞めた。
でも職業PGとしての師匠は最初の指導担当の先輩だと思ってる。
コボラ達と意思疎通が困難な中で、自分が新人の頃には先輩に世話になった
今度はおいらの番だって指導にあたってくれたおかげで今がある。
315 ：仕様書無しさん：2007/02/21(水) 22:49:58
316 ：仕様書無しさん：2007/02/21(水) 23:31:17
WindowsからAS400に接続して売上情報を
作成するプログラムを開発したが、もの凄かった
１テーブルのサイズが軽く3Kを越え
しかも、レスポンスが悪いからインデックスを張りましょう～と
提案するとインデックスって何？
論理ファイル作ればいいじゃんって言われたorz
（後で調べたら論理ファイル＝ビュー
彼らはＲＤＢの概念も知らないし、
勿論、ＳＱＬ文も知らない怪物だった
作成するプログラムを開発したが、もの凄かった
１テーブルのサイズが軽く3Kを越え
しかも、レスポンスが悪いからインデックスを張りましょう～と
提案するとインデックスって何？
論理ファイル作ればいいじゃんって言われたorz
（後で調べたら論理ファイル＝ビュー
彼らはＲＤＢの概念も知らないし、
勿論、ＳＱＬ文も知らない怪物だった
>>316
AS400ってまだいるんだね。
AS400ってまだいるんだね。
>>316
逆説的なんだが、そのIBMのRDBの根源のひとつがAS400なワケだが。
ここからDB2が生まれたとも言えるワケだし。
ちなみに今は中身がRS/6000相当なので、「ちゃんと設計すれば」
超安定かつそこそこ高速なRDBだ（OSとDBが融合してるので説明がムズい）
まー、けどRDBの概念知らんかったりSQL知らん奴多いよな。
論理ファイルは論理ファイルでいいとこあるよ。古代言語(RPG)使いにとっては。
SQL使いがほとんどの現世ではｲｲﾄｺほとんどないが。
逆説的なんだが、そのIBMのRDBの根源のひとつがAS400なワケだが。
ここからDB2が生まれたとも言えるワケだし。
ちなみに今は中身がRS/6000相当なので、「ちゃんと設計すれば」
超安定かつそこそこ高速なRDBだ（OSとDBが融合してるので説明がムズい）
まー、けどRDBの概念知らんかったりSQL知らん奴多いよな。
論理ファイルは論理ファイルでいいとこあるよ。古代言語(RPG)使いにとっては。
SQL使いがほとんどの現世ではｲｲﾄｺほとんどないが。
319 ：仕様書無しさん：2007/02/22(木) 00:20:06
システム自体は安定してるセキュアだし悪くねーかもね。
しかしいかんせん開発効率悪すぎ。
インターフェースも70年代だし。
COBOLが悪いっていうより、もっと便利な新しいシステムを覚えられなくて
しがみついてる無能な奴が悪いって事だろうな。
CとかSQL使えた上で、必要に応じてCOBOL使ってるならわかるけど、
今の時代までCOBOLしか出来ないってのは、もうその時点で頭悪いから仕方ない。
しかしいかんせん開発効率悪すぎ。
インターフェースも70年代だし。
COBOLが悪いっていうより、もっと便利な新しいシステムを覚えられなくて
しがみついてる無能な奴が悪いって事だろうな。
CとかSQL使えた上で、必要に応じてCOBOL使ってるならわかるけど、
今の時代までCOBOLしか出来ないってのは、もうその時点で頭悪いから仕方ない。
レガシーシステムが奮戦していることが多々あるからやむをえまい。
コボル漬けになった担当者は気の毒。
コボル漬けになった担当者は気の毒。
321 ：仕様書無しさん：2007/02/22(木) 00:25:47
AS400用のODBCなかったっけ
AS400(i5)はデフォルトと言うかJava+SQLがすでにセットアップ済みと言う恐ろしい
実験機と言うかある意味、そこらのLinuxよりも実はオープン系向きな
サーバーだったりするんだが、どうも古代人（W)がCOBOLやRPGに
しがみついている無能連中が多いから不当な評価を受けてる感があるな。
レガシーから最新技術まで使えるのが一応のウリのサーバーなんだが。
実験機と言うかある意味、そこらのLinuxよりも実はオープン系向きな
サーバーだったりするんだが、どうも古代人（W)がCOBOLやRPGに
しがみついている無能連中が多いから不当な評価を受けてる感があるな。
レガシーから最新技術まで使えるのが一応のウリのサーバーなんだが。
取ってきた結果がソートされてるなんてどうやって証明するんだ？
万が一順番通りになっていなかったらどうするんだよ！
だから１件ずつ取ってきて調べるんだ！解ったか！！
うん、あなたをCOBOLERの巣に帰さなければいけないことは解ったｗ
万が一順番通りになっていなかったらどうするんだよ！
だから１件ずつ取ってきて調べるんだ！解ったか！！
うん、あなたをCOBOLERの巣に帰さなければいけないことは解ったｗ
ＡＳ４００でストアド使ってるとえらい事になってるよ
素直にＲＰＧでいいと思う。バッチ部分は。
素直にＲＰＧでいいと思う。バッチ部分は。
>>326
kwsk
kwsk
COBOLerの書くストアドなんて
select * from hoge;
とか平気で書いてそうだな。
それで、パフォーマンスがでなくて
RPGでいいとか言っていたら頭おかしいと思うが。
select * from hoge;
とか平気で書いてそうだな。
それで、パフォーマンスがでなくて
RPGでいいとか言っていたら頭おかしいと思うが。
慣れたもんでやれって意味
それは慣れとか不慣れの問題ではなく、
COBOLerは無能って意味だと思うがｗ
まあ、自称慣れているRPGプログラマーでも
アフォみたいに論理ファイル作りまくったり、
ロックせずにファイル更新しようとしてエラーがでて
「おかしい」とかヌかしている素人がいたりするからなー。
COBOLerは無能って意味だと思うがｗ
まあ、自称慣れているRPGプログラマーでも
アフォみたいに論理ファイル作りまくったり、
ロックせずにファイル更新しようとしてエラーがでて
「おかしい」とかヌかしている素人がいたりするからなー。
331 ：おめこ：2007/02/25(日) 20:25:12
いやー久々に見たら、案外盛り上がってるな。
うれしい。
この調子で、コボラ叩こうぜ！
うれしい。
この調子で、コボラ叩こうぜ！
やはり一番ウザく思うのは、
Key,日計１,日計２,・・・・,日計50
みたいなやつだとおもう。
Key,日計１,日計２,・・・・,日計50
みたいなやつだとおもう。
READ一回で結局OCCURS配列にぶっ込んで
所望の処理してレコード変数に代入してREWRITEな。
I/F部分を隠蔽すれば嫌なCOBOLerの呪縛から現実逃避できる自分を最近発見した。
所望の処理してレコード変数に代入してREWRITEな。
I/F部分を隠蔽すれば嫌なCOBOLerの呪縛から現実逃避できる自分を最近発見した。
334 ：仕様書無しさん：2007/02/26(月) 00:47:33
ボコラ課長が作ったストアドは内部でコミットするんだ…
だからストアド避けてトランザクションはるんだ…
やめよーって言っても皆いまさらマンドクセなんだ…
なんでそーなったか？○ＢＭのサンプルコードが内部コミットしてっから
一連登録処理のそこだけ外出しにするの気持ち悪くないの…？
おいらは禿敷く吐き気がするよ…
直したいのに共通部分はさわるなってヒドイヨ
だからストアド避けてトランザクションはるんだ…
やめよーって言っても皆いまさらマンドクセなんだ…
なんでそーなったか？○ＢＭのサンプルコードが内部コミットしてっから
一連登録処理のそこだけ外出しにするの気持ち悪くないの…？
おいらは禿敷く吐き気がするよ…
直したいのに共通部分はさわるなってヒドイヨ
337 ：仕様書無しさん：2007/02/26(月) 19:17:13
>>336
確かに、喪前らに禿同だが、
ストアドをCallした後に、他の更新処理があって
それそれでエラーになったら、全部ROLLBACKしたいけど
出来ないジャマイカー。（正常系には問題ない？が、異常系
に問題アリ）
と言っておるように思う。
ちがう？>>334
確かに、喪前らに禿同だが、
ストアドをCallした後に、他の更新処理があって
それそれでエラーになったら、全部ROLLBACKしたいけど
出来ないジャマイカー。（正常系には問題ない？が、異常系
に問題アリ）
と言っておるように思う。
ちがう？>>334
ただストアドを使いたかっただけなのでは
個人的にはCOBOLerだとコミットすら知らん印象があるんだが。
あとIBMのどんなサンプルコードかしらんけど、
DB2UDBやDB2/400は普通に機能ケースに従ったサンプルだった。
しかし、>>334の発言はどーもアレなんだが。
トランザクションの使い方はシステムによってまちまちだから
第三者がどーこーいうのは難しい罠。
まあ、長く動いているシステム見ると直したくなる心境は
解らないでもないが、そういうのは暇人プログラマの
オナニーであるケースが多いな。
あとIBMのどんなサンプルコードかしらんけど、
DB2UDBやDB2/400は普通に機能ケースに従ったサンプルだった。
しかし、>>334の発言はどーもアレなんだが。
トランザクションの使い方はシステムによってまちまちだから
第三者がどーこーいうのは難しい罠。
まあ、長く動いているシステム見ると直したくなる心境は
解らないでもないが、そういうのは暇人プログラマの
オナニーであるケースが多いな。
鉄則：問題なく動くソースはどんなに腐っていても手を触れるな。
ちゃんと理由や目的があり、ちゃんとテストするなら別に
ソースをいじるのは悪くないと思うけど、
キモいから、と言う理由でいじるべきではないな。
経験則でその「鉄則」があるシステムは多くの場合グダグダだしな。
極稀に天才エンジニア(?)が気ままにつくったっぽいシステムの
方が美しかったりするのはある。
#たぶん、一人で全て作ったと思われ
ソースをいじるのは悪くないと思うけど、
キモいから、と言う理由でいじるべきではないな。
経験則でその「鉄則」があるシステムは多くの場合グダグダだしな。
極稀に天才エンジニア(?)が気ままにつくったっぽいシステムの
方が美しかったりするのはある。
#たぶん、一人で全て作ったと思われ
343 ：仕様書無しさん：2007/02/26(月) 22:45:23
『コボラ』で検索したら、コボラ叩いてるっぽいスレはここともう一つしかなかった。
おかしい。コボラをのさばらしてていいのか！？
もっと、コボラ叩きスレを立てるんだ！！
おかしい。コボラをのさばらしてていいのか！？
もっと、コボラ叩きスレを立てるんだ！！
344 ：仕様書無しさん：2007/02/26(月) 23:30:19
１．高学歴、キモヲタ。３５歳。
GUI、RDBでの開発をまったく知らないコボラ。
２．高卒、普通の人。２５歳。
VB厨。
使うならどっち？
GUI、RDBでの開発をまったく知らないコボラ。
２．高卒、普通の人。２５歳。
VB厨。
使うならどっち？
1の方がまだ学習能力ありそうだ。
1は、そいつより学歴が上ならアリ
2は、上手いこと鍛えることができればアリ
2は、上手いこと鍛えることができればアリ
マジレスすると、そんな小手先の知識や経験で
使うやつは決めないんだが。
つかDB関連の仕事でSQL使えんやつは既に門前払いだろ。w
使うやつは決めないんだが。
つかDB関連の仕事でSQL使えんやつは既に門前払いだろ。w
>>347
コーダー乙ｗ
コーダー乙ｗ
349 ：仕様書無しさん：2007/02/27(火) 00:50:28
１も２も使う価値がないので、二次受けの会社へ押し込んで三割抜く。
>>348
派遣乙w
派遣乙w
351 ：仕様書無しさん：2007/02/27(火) 19:37:17
１．東大卒、２５歳。
こいつに聞いたらわからないことなど何もないと言うほど
豊富なスキルを持っている。
が、狭量で自己顕示欲が強く、
他人の些細なミスを人目をはばからず罵倒する。
キモオタサディスト。
２．高卒、２５歳。
他業種からの転職で業界未経験。
これから勉強する意欲に溢れ、飲み込みも早い。
性格は明るく素直で誰にでも低姿勢な好青年。
３．５流大卒、２５歳。
業界経験３年。仕事は早いがスキルはたいしたことなく、
（成果物の品質が悪いという意味ではなく、出来ることの範囲が１よりは広くないということ）
技術職に固執しているわけでもない。
生意気だがしゃべりは面白く、職場のムードメーカ的存在。
遊び人。
使うならどれ？
こいつに聞いたらわからないことなど何もないと言うほど
豊富なスキルを持っている。
が、狭量で自己顕示欲が強く、
他人の些細なミスを人目をはばからず罵倒する。
キモオタサディスト。
２．高卒、２５歳。
他業種からの転職で業界未経験。
これから勉強する意欲に溢れ、飲み込みも早い。
性格は明るく素直で誰にでも低姿勢な好青年。
３．５流大卒、２５歳。
業界経験３年。仕事は早いがスキルはたいしたことなく、
（成果物の品質が悪いという意味ではなく、出来ることの範囲が１よりは広くないということ）
技術職に固執しているわけでもない。
生意気だがしゃべりは面白く、職場のムードメーカ的存在。
遊び人。
使うならどれ？
裁判長、>>351は誘導尋問です。
レッテル貼りが趣味みたいなやつがいるな。
なんか型にはめないと落ち着かないんだろうなぁ。
なんか型にはめないと落ち着かないんだろうなぁ。
354 ：裁判長：2007/02/27(火) 20:37:17
351は
スキルをとるか人格をとるか両方バランスをとるか
ってことが言いたいンジャマイカ？
漏れは使うなら、２か３だな。
１は使うこともあるかもしれんが、必要なことだけ吸収してポヰすればｳﾏｰ。
スキルをとるか人格をとるか両方バランスをとるか
ってことが言いたいンジャマイカ？
漏れは使うなら、２か３だな。
１は使うこともあるかもしれんが、必要なことだけ吸収してポヰすればｳﾏｰ。
なぜこのスレでこんな話題がでるか解らんが、
プログラマーに人格はいらんだろ。
技術職なんだし、できるやつしか必要ない。
そしてCOBOLなんかの案件に豊富なスキルなんか必要ない。
プログラマーに人格はいらんだろ。
技術職なんだし、できるやつしか必要ない。
そしてCOBOLなんかの案件に豊富なスキルなんか必要ない。
自分は、使うなら1>3>2。状況にもよるけどね。
「必要なこと」がどんどん膨張していく業界だから、「吸収してポヰ」なんて無理じゃない？
できても、吸収してポヰしたあとその分自分が働かなくちゃいけないなら本末転倒だよ。
最初から見通せてる仕事なんて少ないし、
困難な局面で頼れるのがいるのであればそっから使うにこしたことない。
ま、COBOLであれば2オンリーで。3も要りません。
「必要なこと」がどんどん膨張していく業界だから、「吸収してポヰ」なんて無理じゃない？
できても、吸収してポヰしたあとその分自分が働かなくちゃいけないなら本末転倒だよ。
最初から見通せてる仕事なんて少ないし、
困難な局面で頼れるのがいるのであればそっから使うにこしたことない。
ま、COBOLであれば2オンリーで。3も要りません。
Cがある意味、技量と言うか美しさを体現できなくもない言語だな。
***hogeなんてやられた日にはプチ殺意が沸いてきたりこなかったり。ｗ
***hogeなんてやられた日にはプチ殺意が沸いてきたりこなかったり。ｗ
コボルの唯一の良い所は、誰が書いても概ね似たような冗長さになることだと聞いたことがある。
363 ：仕様書無しさん：2007/02/28(水) 20:21:38
自分は仕事が出来ると思ってる奴、てぇあげろ。
>>342
二人程度でできる仕事は、人にもよるが、一人でやった方が早く、きれいで、
しかも性能・安定性も上だろう。いま、二人でチームを組まされているんだが
ちょっとインターフェースを変更したりするだけでもいちいち了解を取らないと
いけないんで、スゲー効率悪い。
二人程度でできる仕事は、人にもよるが、一人でやった方が早く、きれいで、
しかも性能・安定性も上だろう。いま、二人でチームを組まされているんだが
ちょっとインターフェースを変更したりするだけでもいちいち了解を取らないと
いけないんで、スゲー効率悪い。
２人チームだと一人でいーじゃん、ってのはあるな。
スキルアップとかそういう２人チームもあるだろうけど。
干渉が最低限になるように分業にしてお互いが好きにやるってのもあるだろうけど。
スキルアップとかそういう２人チームもあるだろうけど。
干渉が最低限になるように分業にしてお互いが好きにやるってのもあるだろうけど。
>>364-365
おまいらちょっとはアジャイルをだな(ry
おまいらちょっとはアジャイルをだな(ry
アジャイルを実現するには、開発スタッフに並かそれ以上なスキルが
要求されるんだよな。
ただ、開発スタッフが一流のエンジニアだと単独プレイと言うと印象悪いが、
マネージメントを上手くやれば少ない人数で効率のいい開発が出来る。
しかし、現実には頭悪いマネージャーがエンジニアの能力を殺すケースが
多いわけだ。
まー、COBOLerで一流と呼ばれるエンジニアにはまだ出会ったことはないんだが。
要求されるんだよな。
ただ、開発スタッフが一流のエンジニアだと単独プレイと言うと印象悪いが、
マネージメントを上手くやれば少ない人数で効率のいい開発が出来る。
しかし、現実には頭悪いマネージャーがエンジニアの能力を殺すケースが
多いわけだ。
まー、COBOLerで一流と呼ばれるエンジニアにはまだ出会ったことはないんだが。
>>367
必要なスキルは対人スキルもな。
必要なスキルは対人スキルもな。
>まー、COBOLerで一流と呼ばれるエンジニアにはまだ出会ったことはないんだが。
自分たちが出来なかったら全て他人のせいにしろ、みたいな他力本願の
思想をたたき込まれて育ったような人が一流と呼ばれるなんて思えないｗ
まぁ一流と呼ばれるような人は（最初COBOLやってても時代の流れを読んで）さっさとサヨナラしている、
というのも有ると思うけど。
自分たちが出来なかったら全て他人のせいにしろ、みたいな他力本願の
思想をたたき込まれて育ったような人が一流と呼ばれるなんて思えないｗ
まぁ一流と呼ばれるような人は（最初COBOLやってても時代の流れを読んで）さっさとサヨナラしている、
というのも有ると思うけど。
技術職なんてのは常に知識を吸収して自己啓発しつづける職種だと
思うんだが、COBOLerはそういうのがぜんぜんないやつ多いよな。
なんか非効率的な作業をしているから「こうした方がもっと効率的になるよ」
とアドバイスしたらそのCOBOLerは「私はいままでこうやってやってきました」
と漏れより年下のヤツがホザきました。
素人時代に最初に覚えた事で「漏れは一人前」と勘違いして、
素人技を伝統的にひきついでいくんだよなぁ。
思うんだが、COBOLerはそういうのがぜんぜんないやつ多いよな。
なんか非効率的な作業をしているから「こうした方がもっと効率的になるよ」
とアドバイスしたらそのCOBOLerは「私はいままでこうやってやってきました」
と漏れより年下のヤツがホザきました。
素人時代に最初に覚えた事で「漏れは一人前」と勘違いして、
素人技を伝統的にひきついでいくんだよなぁ。
>>370
また、そういうのが右も左もわからん奴にはとっつきやすいから性質が悪い。
また、そういうのが右も左もわからん奴にはとっつきやすいから性質が悪い。
COBOLerって変わらない事は良い事だっていう変な安定志向があるから、
常に知識を吸収して自己啓発しつづけるという進化を要求することがそもそも間違いだと思われ。w
常に知識を吸収して自己啓発しつづけるという進化を要求することがそもそも間違いだと思われ。w
変える理由、考えない理由を無視すのは、コボラもJava厨も同じくらい問題
＞「変わらない事は良い事だ」っていうのは別に必ずしも悪いことじゃないだろう。
かならずしも悪い事ではないが、この職場ではほとんどの場合悪いことだろう。
だから各所で叩かれるわけで。
そのCOBOLerがスーパーハッカーならともかく、素人もしくは素人レベルの老人が
「変わらない事は良い事だ」なんて主張されたら「アフォか」の一言だな。
かならずしも悪い事ではないが、この職場ではほとんどの場合悪いことだろう。
だから各所で叩かれるわけで。
そのCOBOLerがスーパーハッカーならともかく、素人もしくは素人レベルの老人が
「変わらない事は良い事だ」なんて主張されたら「アフォか」の一言だな。
その素人レベルにすら負けてるお前らが何を言っても無駄。
ウヲ、こうやってCOBOLerは自分の殻に閉じこもって
自分ひとりだけ「勝った気分」でいるんだろうなぁ。
哀れな存在だな。
自分ひとりだけ「勝った気分」でいるんだろうなぁ。
哀れな存在だな。
そうなんだよ。COBOLer爺は哀れな存在なんだよ。
Java厨・VB厨も20年後には、今のCOBOLerと同じ扱い。明日は我が身ｗ
>>379
可能な限り手広くやらなきゃ、何厨でも同じなんだよ。
可能な限り手広くやらなきゃ、何厨でも同じなんだよ。
今日もコボルとコーディング♪
若いオナノコがこの時期に配属＆コボルでOJTだと...
泣いていいか？(TT
泣いていいか？(TT
384 ：仕様書無しさん：2007/03/13(火) 21:01:17
>>そのオナノコ、、、かぁぃぃ？(ﾟДﾟ)ﾊｧﾊｧ
385 ：仕様書無しさん：2007/03/13(火) 22:07:20
>>379
cobolやったから馬鹿なんじゃないよ。
こんだけ新しい技術が出てきてるのにcobolしか出来ないアホさと
学習能力のなさが問題なんだよ。
俺は、都度新しい技術を身につけてるんで、当分は大丈夫。
５０までがんばりゃ、あとは余力でやれるだろう。
cobolやったから馬鹿なんじゃないよ。
こんだけ新しい技術が出てきてるのにcobolしか出来ないアホさと
学習能力のなさが問題なんだよ。
俺は、都度新しい技術を身につけてるんで、当分は大丈夫。
５０までがんばりゃ、あとは余力でやれるだろう。
まあ、妄想くらい許してやれ。ｗ
>>386 ﾁﾝﾁﾝ
奈津美ちゃんについての暴露はまだですか ﾉｼ☆
奈津美ちゃんについての暴露はまだですか ﾉｼ☆
並の娘はもう既に辞めてます。
ごめんなさいorz
ごめんなさいorz
391 ：仕様書無しさん：2007/03/17(土) 00:13:33
>>387
釣られる、お前の脳味噌がめでたい。
釣られる、お前の脳味噌がめでたい。
392 ：仕様書無しさん：2007/03/17(土) 00:15:39
>>391
過疎スレの二日前にレスつけるお前の脳味噌もめでたい ｗ
過疎スレの二日前にレスつけるお前の脳味噌もめでたい ｗ
>>391,392
おめでとう
おめでとう
ありがとう
>>391
さすがにコボラでもあれが「釣られた」と思えるほど頭の固いヤツは居ないと思う。
さすがにコボラでもあれが「釣られた」と思えるほど頭の固いヤツは居ないと思う。
396 ：仕様書無しさん：2007/03/18(日) 23:51:42
>>395
おめでとう
おめでとう
自分がバカにされたと思って必死なんだろうな。
さっさと汎用機の脇にもどればいいのに。
さっさと汎用機の脇にもどればいいのに。
>>397
おめでとう
おめでとう
ありがとうコボラ。
まああれですかね、ゆりかもめの線路の検査は耳で音聞いてやってるってのと
同じで、古い職人ワザをあえて採用する場合もあって、そういう所で COBOLer
は細々と生きていくんだと思いますが、いずれ世界で最後の COBOLer となって
人間国宝となって息絶えて逝くんでしょう。合掌。
同じで、古い職人ワザをあえて採用する場合もあって、そういう所で COBOLer
は細々と生きていくんだと思いますが、いずれ世界で最後の COBOLer となって
人間国宝となって息絶えて逝くんでしょう。合掌。
俺、perlでだらだら書かれたCGIを解析するくらいならコボルのほうがマシだと考えてしまうかもしれん。
や、コボルはFの新人研修以来、見たこともないんですけどね。
や、コボルはFの新人研修以来、見たこともないんですけどね。
perlでだらだらがよー解らんが、初心者らしく組んだperlを読むのが苦痛なのか
エキスパートが組んだ狂った様なperlを読むのが苦痛なのかどっちなんだろう。
エキスパートが組んだ狂った様なperlを読むのが苦痛なのかどっちなんだろう。
どっちも嫌じゃ。
405 ：仕様書無しさん：2007/03/23(金) 20:51:01
>>404
お前の書き込みは、激しく無意味。
お前の書き込みは、激しく無意味。
>>405
お前もな。
お前もな。
407 ：仕様書無しさん：2007/03/23(金) 20:57:10
>>406
このまま行くと、無限に再起呼び出しが続く件。
このまま行くと、無限に再起呼び出しが続く件。
>>407
よしやってみよう。
よしやってみよう。
Stack over flow.
core dump.............
「再起」呼び出しって…。
叩いても叩いてもゾンビのごとく這い上がってくるのか？
叩いても叩いてもゾンビのごとく這い上がってくるのか？
PASCALは画期的だったな
横長って・・・このスレ面白かった
皆同じ経験しているんだね
皆同じ経験しているんだね
「リレーション」というものを本当に知らないからな。
417 ：仕様書無しさん：2007/03/26(月) 21:50:06
俺、ある意味コボラ上がりのSE好きだけどな。
なんでかっていうと、そいつらがおるとデスマになるから、
月１５０万とか稼げたりするわけ。
横長DBなんて当然放置 ｗ
文字列型（Char(10)のフィールドに "0010010100" とか ｗ ）フラグも当然放置 ｗ
なんでかっていうと、そいつらがおるとデスマになるから、
月１５０万とか稼げたりするわけ。
横長DBなんて当然放置 ｗ
文字列型（Char(10)のフィールドに "0010010100" とか ｗ ）フラグも当然放置 ｗ
419 ：仕様書無しさん：2007/03/26(月) 22:12:58
うーん、確かにしんどいけどな。
まぁ、それなりの報酬があれば我慢するさ ｗ
もうすぐ、ガキ生まれるしね。
まぁ、それなりの報酬があれば我慢するさ ｗ
もうすぐ、ガキ生まれるしね。
420 ：仕様書無しさん：2007/03/26(月) 22:19:48
421 ：仕様書無しさん：2007/03/26(月) 22:36:14
カリカリするよりニヤニヤしてた方が確かに良いわな
423 ：417：2007/03/26(月) 23:25:40
社員コード０１ ～ 社員コード１０ なんて、
社員マスタ１０枚LEFTJOINしてやるぜ！！！
せっかくインデックスを文字列フラグもSUBSTRで絞込み条件に指定だ！！
かかってこい！！コボラ！！
社員マスタ１０枚LEFTJOINしてやるぜ！！！
せっかくインデックスを文字列フラグもSUBSTRで絞込み条件に指定だ！！
かかってこい！！コボラ！！
424 ：417：2007/03/26(月) 23:32:16
で、リリース後に性能対策でまた、一儲け。ｳﾏー。
コボラはうちでのこづちだ！
コボラはうちでのこづちだ！
人間ここまで墜ちたくないな。
426 ：仕様書無しさん：2007/03/26(月) 23:35:07
TVに出まくり
427 ：417：2007/03/26(月) 23:35:25
いや、コボラの自滅に付き合っているだけだよ ｗ
428 ：仕様書無しさん：2007/03/27(火) 00:06:02
10年くらい前まで現役コボラだったが、正規化の概念なんか15年以上前に習得したぞ。
お前らの周囲のコボラ品質悪すぎ。
まあ、VSAMやIMSは横に行くのも仕方ないが、今どき誰も使っとらんだろ。
俺はその後デルファになって今はジャバラだ。
OOPを理解しないVB厨にはいつも手を焼いている。
お前らの周囲のコボラ品質悪すぎ。
まあ、VSAMやIMSは横に行くのも仕方ないが、今どき誰も使っとらんだろ。
俺はその後デルファになって今はジャバラだ。
OOPを理解しないVB厨にはいつも手を焼いている。
429 ：仕様書無しさん：2007/03/27(火) 00:09:03
cobol85
>>428
はよ出世しろや ｗ
はよ出世しろや ｗ
>>430
しっ・・・
しっ・・・
一生現役(笑)
コボラは2001年問題だが
こいつは2007年問題を再度引き起こしそうだなw
コボラは2001年問題だが
こいつは2007年問題を再度引き起こしそうだなw
一生底辺か・・・
そんな心配しなくてもそのうち便所掃除とかに回してもらえると思うが。
そんな心配しなくてもそのうち便所掃除とかに回してもらえると思うが。
436 ：仕様書無しさん：2007/03/27(火) 21:20:04
>>432
次の仕事考えとけよ。
次の仕事考えとけよ。
ストゼロ剛毅使いで荒稼ぎ
438 ：432：2007/03/27(火) 22:54:50
で、おまいらは何歳で現役引退の予定？
マ 板 で 顔 真 っ 赤
>>文字列型（Char(10)のフィールドに "0010010100" とか ｗ ）フラグも当然放置 ｗ
俺この前それに近い設計をしてしまったorz
俺この前それに近い設計をしてしまったorz
使う側にも選ぶ権利がある
いつも見ているテーブルの仕様が、そんなのばっかりなので真似てみたorz
今後流されないように設計します。(__)
今後流されないように設計します。(__)
まあ謙虚な新人は、
「一見おかしく見えるけど、ベテランたちがやってるのなら何か意味があるんだろう」
とか思って真似しちゃうかもしれんな。
まさか職場のベテラン連中が馬鹿揃いだなんて思わないよなあ、普通の業界なら。
「一見おかしく見えるけど、ベテランたちがやってるのなら何か意味があるんだろう」
とか思って真似しちゃうかもしれんな。
まさか職場のベテラン連中が馬鹿揃いだなんて思わないよなあ、普通の業界なら。
で、一時期過剰に職場のバカどもに反応するんだよな。
だんだん疲れて、気がついたときには、自分も職場のバカと化してる。
だんだん疲れて、気がついたときには、自分も職場のバカと化してる。
446 ：仕様書無しさん：2007/03/28(水) 22:48:36
>>438 は 出世しちゃったのかな？
COBOLではこうだった、だから正しい、なんて言うのは
日本で右車線走って「アメリカでは右側通行で良かった、日本の法律がおかしい」
って言ってるのと同じなんだよな・・・
日本で右車線走って「アメリカでは右側通行で良かった、日本の法律がおかしい」
って言ってるのと同じなんだよな・・・
そんなにコボラー嫌いなら
相手にしなければいいのに。
相手にしなければいいのに。
450 ：438：2007/03/29(木) 10:11:33
>>446
24歳くらいまでの仕事は、いわゆる「コーダ」に近かったかな。
しれ以降はずっと「プログラマ」だったから、その意味では俺は24歳で現役引退したのか？？
自分が考える「現役引退」ってのは、自分では１行もコードを書かない（間接的にも）立場になるってことだろうな。
>>447
残念ながら、今の会社にはこれ以上上のポストが無い。
だから出世できないんだ。
24歳くらいまでの仕事は、いわゆる「コーダ」に近かったかな。
しれ以降はずっと「プログラマ」だったから、その意味では俺は24歳で現役引退したのか？？
自分が考える「現役引退」ってのは、自分では１行もコードを書かない（間接的にも）立場になるってことだろうな。
>>447
残念ながら、今の会社にはこれ以上上のポストが無い。
だから出世できないんだ。
>>450
かわいそうです（；ω；）ﾌﾞﾜｯ
かわいそうです（；ω；）ﾌﾞﾜｯ
出世に転職は含まれません
うちの会社に50代の老練なコボラーがいるね。
役職はなくて、主に保守（コード修正）や教育、テストを担当してるな。
もちろんシステムの仕組みを熟知してるからただのPGではないな。
俺もあんな感じになるのかねぇ・・・
役職はなくて、主に保守（コード修正）や教育、テストを担当してるな。
もちろんシステムの仕組みを熟知してるからただのPGではないな。
俺もあんな感じになるのかねぇ・・・
454 ：仕様書無しさん：2007/03/29(木) 18:44:07
457 ：仕様書無しさん：2007/03/29(木) 21:13:10
自分でフォローしてどうすんだよ ｗ
458 ：1：2007/03/29(木) 21:14:35
お、久々にみたら、結構伸びてるなー！！
うれすぃー！！
うれすぃー！！
うれしいなら黙ってろ。
その発言のためにこのスレは伸び悩むだろう。
その発言のためにこのスレは伸び悩むだろう。
461 ：仕様書無しさん：2007/03/29(木) 21:27:28
462 ：仕様書無しさん：2007/03/29(木) 21:28:43
2chで叩かれるって一種の才能よな？
そんな才能なんてｲﾗﾈ
>>457
俺の高度なジョークがここのバカには理解できないと思ってしまったんだろうなwwww
俺の高度なジョークがここのバカには理解できないと思ってしまったんだろうなwwww
465 ：450：2007/03/29(木) 23:11:33
で、お前らオレのどこを叩きたいわけ？
昔：COBOLでメインフレームばりばり
今：JavaでOOPさくさく
守備範囲：要件定義～外人プログラマの尻拭いまで
肩書き：代表取締役
年収：非公開
将来の夢：70歳まで現役プログラマ
昔：COBOLでメインフレームばりばり
今：JavaでOOPさくさく
守備範囲：要件定義～外人プログラマの尻拭いまで
肩書き：代表取締役
年収：非公開
将来の夢：70歳まで現役プログラマ
匿名掲示板で肩書き自慢されても困る罠。
そういう馴れ合いや自慢合戦はmixi辺りでやってくれ。
そういう馴れ合いや自慢合戦はmixi辺りでやってくれ。
>>465
メインフレームとOOPが同列？wwwww
メインフレームとOOPが同列？wwwww
>>471
代表取締役で打ち止めって時点でどうかと思うが。
特に資格など必要ないから禁治産者などでない限り誰でも就任できるし。
もっと就任することが難しい地位になってから言ってくれ。
天皇とかだったら確かにそれ以上出世しようがないのも理解できるのだがな。w
代表取締役で打ち止めって時点でどうかと思うが。
特に資格など必要ないから禁治産者などでない限り誰でも就任できるし。
もっと就任することが難しい地位になってから言ってくれ。
天皇とかだったら確かにそれ以上出世しようがないのも理解できるのだがな。w
とりあえず>>471は空気を読めないから叩かれている事を察しろ。
昔はテーブルって単語はあんまし使われてなかった気がするが。
RDBって呼ばれ方も稀だと思うので、なんでもDBなんじゃねーの？
そおいや、スキーマってCOBOLerの人は現代でもあんまし使わんよな。
RDBって呼ばれ方も稀だと思うので、なんでもDBなんじゃねーの？
そおいや、スキーマってCOBOLerの人は現代でもあんまし使わんよな。
補足でスマンが、コードテーブルとかメッセージテーブルという
使われ方はしていたけど「列と行の集合体」って意味のテーブルを
使っている人は少ないって意味な。
使われ方はしていたけど「列と行の集合体」って意味のテーブルを
使っている人は少ないって意味な。
>>475
「横長」などという幼稚な表現はいいのか。
「横長」などという幼稚な表現はいいのか。
ファイル
「非リレーショナル」とか
「非正規形」とか
「非正規形」とか
幼稚じゃないだろうけどダサい
483 ：仕様書無しさん：2007/03/30(金) 19:26:53
484 ：仕様書無しさん：2007/03/30(金) 19:28:13
485 ：仕様書無しさん：2007/03/30(金) 19:32:22
>>471
>>早く出世しろって煩いから、これ以上どうやって出世するのか教えろって意味。
えー、450さんの会社はエンドユーザ直撃のSIerさんでしょうか？
それとも、元請SIerの手下でしょうか？
はたまた、中小派遣会社の枝ですか？
>>早く出世しろって煩いから、これ以上どうやって出世するのか教えろって意味。
えー、450さんの会社はエンドユーザ直撃のSIerさんでしょうか？
それとも、元請SIerの手下でしょうか？
はたまた、中小派遣会社の枝ですか？
零細偽装請負？
出世とか興味ないけど、とことん出世するならゲイツに並ぶか追い越すかだろうな。
それ以下は結局「ゲイツ以下」としか判断しようがない。
俺は出世よりも名誉よりも金が必要だ。
それ以下は結局「ゲイツ以下」としか判断しようがない。
俺は出世よりも名誉よりも金が必要だ。
ゲイツは経営者としてはいいのかもしれんが、
エンジニア的には憧れとかはないなー。
なんかMSは「所詮パクリ企業」ってイメージしかないし。
まー、いいんじゃない、偽装派遣の社長さんでもさｗ
エンジニア的には憧れとかはないなー。
なんかMSは「所詮パクリ企業」ってイメージしかないし。
まー、いいんじゃない、偽装派遣の社長さんでもさｗ
偽装派遣の社長で、一生現役とか最悪だ
出世≠技術者じゃねーの？
技術者のままの出世のゴールは、企業なり大学なりに博士待遇で入って好きな事できるようになることだと思う
２ｃｈで煽られる代表取締役 ｗ
ERPパッケージの標準テーブルも100項目ぐらい余裕であるんだが
コボラーの設計するテーブルってどれぐらいの項目なのかね。
コボラーの設計するテーブルってどれぐらいの項目なのかね。
>>493
とりあえず365日分のカラムが保持できないDBは全てクソ。
とりあえず365日分のカラムが保持できないDBは全てクソ。
漏れは金融機関のサブシステムで400弱のを見たことがある。
ただ、コレは顧客側もAccessと言うかExcelに染まっているので
COBOLerとVB厨のコラボとも呼べる作品なのだろう。
ただ、コレは顧客側もAccessと言うかExcelに染まっているので
COBOLerとVB厨のコラボとも呼べる作品なのだろう。
Accessでは255までしかカラムが使えない件に切れるバカコボラー
まさに...
まさに...
2テーブル作って、行番号でリンク
>>497
orz
orz
枝番振って同じテーブルで2レコード使うようなロジックにする
1table-1column-1rowだっ。
create table hoge (
col text null
);
これで完璧
col text null
);
これで完璧
ぬあぁ！！！
修行不足でしたorz
修行不足でしたorz
505 ：仕様書無しさん：2007/04/01(日) 18:11:29
507 ：仕様書無しさん：2007/04/01(日) 18:59:15
時代はコボルからRPGへ
508 ：仕様書無しさん：2007/04/03(火) 18:25:48
無知は罪、だ・・・。
Part7 データベースにまつわる怖い話
http://itpro.nikkeibp.co.jp/article/COLUMN/20070320/265660/
(前略)
> しかし，そのような集計処理を行わなくても，集合関数（SUM）と
> GROUP BY句を使えば，グループごとの集計を一つのSQL文で計算させ
> られるのである。そのことを担当者に告げると「えっ，SQLってそんな
> こともできるんですか！」と驚く始末。
>
> ストアドプロシジャでカーソルを使うような“凝った”プログラムを
> 書いておきながら，SQLの基本的な関数を知らなかったのである。
> 集合関数を使って処理を書き直すと，数十行あったプログラムが
> 数行で済んでしまった。
(中略)
> この件は，バッチ処理のSQL文の書き方やインデックスが作成
> されていないのが直接の原因であった。だが，もっと根本的な
> 原因は，RDBの特性を知らずに設計してしまったことにある。
> 全体として，汎用機アプリケーションでファイルを順次処理する
> ようなイメージで設計してしまったためであろう。不必要な中間
> テーブルが多数あり，無駄なバッチ処理が数多くあった。
Part7 データベースにまつわる怖い話
http://itpro.nikkeibp.co.jp/article/COLUMN/20070320/265660/
(前略)
> しかし，そのような集計処理を行わなくても，集合関数（SUM）と
> GROUP BY句を使えば，グループごとの集計を一つのSQL文で計算させ
> られるのである。そのことを担当者に告げると「えっ，SQLってそんな
> こともできるんですか！」と驚く始末。
>
> ストアドプロシジャでカーソルを使うような“凝った”プログラムを
> 書いておきながら，SQLの基本的な関数を知らなかったのである。
> 集合関数を使って処理を書き直すと，数十行あったプログラムが
> 数行で済んでしまった。
(中略)
> この件は，バッチ処理のSQL文の書き方やインデックスが作成
> されていないのが直接の原因であった。だが，もっと根本的な
> 原因は，RDBの特性を知らずに設計してしまったことにある。
> 全体として，汎用機アプリケーションでファイルを順次処理する
> ようなイメージで設計してしまったためであろう。不必要な中間
> テーブルが多数あり，無駄なバッチ処理が数多くあった。
これあるあるやな～ 松本君！
>ストアドプロシジャでカーソルを使うような“凝った”プログラム
凝ってない凝ってないｗ
阿呆はアプリケーション内でもストアド内でも
ぐるぐる自力ループが大好き。
凝ってない凝ってないｗ
阿呆はアプリケーション内でもストアド内でも
ぐるぐる自力ループが大好き。
>>510
ふぇっちなんですね？
ふぇっちなんですね？
SQL を知らないやつに RDB を使うプログラムを任せたのが敗因。
513 ：仕様書無しさん：2007/04/03(火) 21:07:45
514 ：仕様書無しさん：2007/04/03(火) 21:18:18
515 ：仕様書無しさん：2007/04/03(火) 21:57:40
>>508
コボラのキショさがよくわかる。
コボラのキショさがよくわかる。
516 ：仕様書無しさん：2007/04/04(水) 10:37:32
事実は小説より奇なり。
>>514
ヴビ厨も同じことをしてくれる。
ヴビ厨も同じことをしてくれる。
518 ：仕様書無しさん：2007/04/04(水) 18:49:21
>>508
>>「やはりオープン系RDBは使えない？」
何かにつけて、DBや開発ツールのせいにするのもコボラの特徴。
なんせ、彼らはこの道１０年２０年のベテランだからな ｗ
そりゃ、自分に使えないものは糞に決まってるさ ｗ
>>「やはりオープン系RDBは使えない？」
何かにつけて、DBや開発ツールのせいにするのもコボラの特徴。
なんせ、彼らはこの道１０年２０年のベテランだからな ｗ
そりゃ、自分に使えないものは糞に決まってるさ ｗ
519 ：仕様書無しさん：2007/04/04(水) 18:53:30
520 ：仕様書無しさん：2007/04/04(水) 18:56:16
DBサーバに比べてアプリケーションサーバが圧倒的に性能が良い場合は
あえて集合関数を使わない手もあるが、存在自体を知らんとは・・・
あえて集合関数を使わない手もあるが、存在自体を知らんとは・・・
あいつらにアプリケーションサーバという概念があるのか？
そもそもDBサーバという概念があるのか？
「DBサーバ(多重)＋アプリサーバ(多重)ですから、処理をガンガン投げて下さいね！」
とインフラ設計・設定をやってあげたら、思い切りVBクライアント側で処理回しやがった元コボラー死ね！
そもそもDBサーバという概念があるのか？
「DBサーバ(多重)＋アプリサーバ(多重)ですから、処理をガンガン投げて下さいね！」
とインフラ設計・設定をやってあげたら、思い切りVBクライアント側で処理回しやがった元コボラー死ね！
いや、例えばJOIN
非常に単純計算すると1000レコード×1000レコードのスキャンになる。
そういうのは端末で中間表実装してやってオンラインリスクを下げる。
また、年齢項目等の導出項目も、selectされたレコード分計算される。
こういうのも端末でアドホックに計算してやってオンラインリスクを下げる。
こういうアドホックにやる部分が必ずしもアプリ鯖側でやっているとは限らないと考えて、
クライアント実装して、リスクを下げるのがコボラの考え方。
仕様書がザルじゃなければ・・
非常に単純計算すると1000レコード×1000レコードのスキャンになる。
そういうのは端末で中間表実装してやってオンラインリスクを下げる。
また、年齢項目等の導出項目も、selectされたレコード分計算される。
こういうのも端末でアドホックに計算してやってオンラインリスクを下げる。
こういうアドホックにやる部分が必ずしもアプリ鯖側でやっているとは限らないと考えて、
クライアント実装して、リスクを下げるのがコボラの考え方。
仕様書がザルじゃなければ・・
524 ：仕様書無しさん：2007/04/04(水) 20:27:00
525 ：仕様書無しさん：2007/04/04(水) 20:30:26
なんでJavaのバカってこうもしょうもないことで偉そうなのかな
527 ：仕様書無しさん：2007/04/04(水) 21:07:48
なんでコボルのバカって勤続年数だけで偉そうなのかな
>>525
お、コボラ参戦か！！？
お、コボラ参戦か！！？
529 ：仕様書無しさん：2007/04/04(水) 21:18:54
>>525
お前、偉そうだな。
お前、偉そうだな。
530 ：仕様書無しさん：2007/04/04(水) 22:42:07
盛り上がってまいりマスタ（・∀・）
531 ：仕様書無しさん：2007/04/04(水) 23:03:34
以前関わったシステムで、SQL文（の断片）らしきものが格納されているテーブルを発見した。
そのテーブルから抽出してSQL文を組み立ててそれを使って
SELECTするなんてことをしてた。
『可能なことはなんでもあり』なんですね。
まぁ、これはコボラとは関係ないけど。
そのテーブルから抽出してSQL文を組み立ててそれを使って
SELECTするなんてことをしてた。
『可能なことはなんでもあり』なんですね。
まぁ、これはコボラとは関係ないけど。
532 ：仕様書無しさん：2007/04/04(水) 23:07:08
>>531
普通ならSQLはハードコーディングされるんだからそっちのほうが親切じゃん
普通ならSQLはハードコーディングされるんだからそっちのほうが親切じゃん
533 ：仕様書無しさん：2007/04/04(水) 23:09:17
531じゃないけど、
SQLをハードコーディングしないの？
SQLをハードコーディングしないの？
535 ：仕様書無しさん：2007/04/04(水) 23:13:39
>>534
何度でもコンパイルできると思うなよ！小僧！
何度でもコンパイルできると思うなよ！小僧！
まあ、今時だとO/Rマッパーつかうからなぁ。
537 ：仕様書無しさん：2007/04/04(水) 23:14:51
>>536
ﾀﾞｻｗ
ﾀﾞｻｗ
新手の釣りか？
SQLを知らない一般ﾕｻﾞがアプリを通してSQLの色んな機能を使うってことなら
531って親切じゃまいか。
531って親切じゃまいか。
難しいことをすれば賢いんだよ！！
な、>>532
な、>>532
541 ：仕様書無しさん：2007/04/05(木) 20:55:16
>>540
でも、それには532と同じくらい頭がよくないとできないぞ！
でも、それには532と同じくらい頭がよくないとできないぞ！
542 ：仕様書無しさん：2007/04/06(金) 21:33:58
市ねよ
543 ：399：2007/04/06(金) 22:17:14
http://science6.2ch.net/test/read.cgi/infosys/1111572881/l50
また、勝ち組の俺が来たよ！！
予想通りなんのレスも付いてないな！！ ｗ
こうやって、全部のスレ潰していこうかな！！ ｗ
また、勝ち組の俺が来たよ！！
予想通りなんのレスも付いてないな！！ ｗ
こうやって、全部のスレ潰していこうかな！！ ｗ
544 ：仕様書無しさん：2007/04/07(土) 00:03:37
>>542
誰に言ってるかまったく見当がつかない。
誰に言ってるかまったく見当がつかない。
545 ：仕様書無しさん：2007/04/12(木) 21:47:52
今日、仕様書のレビューがあった。
仕様書に『ハードコーディング』という語句を使ったら
コボラに怒られた。
ハードコーディングそのものがいけなかったわけではないらしく、
語句の意味がわからなかったらしい ｗ そこにいるそのコボラ以外の全員は理解していた ｗ
ウケタ。
みんなが笑ったら、『何がおかしい！？』ってまた怒られたので
更に、受けた。
さらに笑ったら『おい！！失礼だぞ！！』とか言い出したので
もう、腸がねじ切れるかと思った。
いい機会なので、コレまでのしょぼい仕事ぶりを糾弾してやった。
ここでよく話題になっている、横長DBと文字列フラグをネタに使わせてもらった。
（御多分に漏れず奴も同じことやってたのでな ｗ）
コボラは半泣きで会議室をでて行こうとしたが、
漏れが『さぼんなや！！』っていうとまた席についた。
しばらくして、そのコボラを見ると目をこすっていたので
また、ウケて笑ったけど、今度は反撃してこなかったｗ
とても、面白いレビューだった。
仕様書に『ハードコーディング』という語句を使ったら
コボラに怒られた。
ハードコーディングそのものがいけなかったわけではないらしく、
語句の意味がわからなかったらしい ｗ そこにいるそのコボラ以外の全員は理解していた ｗ
ウケタ。
みんなが笑ったら、『何がおかしい！？』ってまた怒られたので
更に、受けた。
さらに笑ったら『おい！！失礼だぞ！！』とか言い出したので
もう、腸がねじ切れるかと思った。
いい機会なので、コレまでのしょぼい仕事ぶりを糾弾してやった。
ここでよく話題になっている、横長DBと文字列フラグをネタに使わせてもらった。
（御多分に漏れず奴も同じことやってたのでな ｗ）
コボラは半泣きで会議室をでて行こうとしたが、
漏れが『さぼんなや！！』っていうとまた席についた。
しばらくして、そのコボラを見ると目をこすっていたので
また、ウケて笑ったけど、今度は反撃してこなかったｗ
とても、面白いレビューだった。
いいなー！！
オレもコボラいじめたいなー。
オレもコボラいじめたいなー。
547 ：仕様書無しさん：2007/04/12(木) 22:02:16
>>547
許したところで再発しては意味が無い。
改善できるような奴ならかまわないが、違うから叩かれるわけで…
まぁ、職場の非コボラ全員が>>417見たいな奴なら、叩かないでアホな事を延々繰り返してもらったほうが良いのだろうけど。
許したところで再発しては意味が無い。
改善できるような奴ならかまわないが、違うから叩かれるわけで…
まぁ、職場の非コボラ全員が>>417見たいな奴なら、叩かないでアホな事を延々繰り返してもらったほうが良いのだろうけど。
549 ：仕様書無しさん：2007/04/12(木) 22:19:47
ハードコーディングって何？
３Ｄ？
３Ｄ？
550 ：仕様書無しさん：2007/04/12(木) 22:25:17
コードをハードディスクに格納しておくこと。
551 ：仕様書無しさん：2007/04/12(木) 22:36:15
>>549
TDKのDVD-R
TDKのDVD-R
>>549-551
お ま え ら ｗ
お ま え ら ｗ
553 ：仕様書無しさん：2007/04/12(木) 22:44:32
555 ：仕様書無しさん：2007/04/12(木) 22:49:36
プログラマを壊すのがお好き
556 ：仕様書無しさん：2007/04/12(木) 22:53:21
>>554
どうやろな？？
あくまでオレが一緒にやってきた連中に限って言えることだが、
脱落する人って、『デスマの原因を作った人（作ったとされる人）』
である場合が、多いようだぞ。
それ以外は案外、気楽にやてるみたいよ。
まぁ、あくまでオレの周りにいる（いた）連中を
オレが客観的に見た感じでは、だけども。
どうやろな？？
あくまでオレが一緒にやってきた連中に限って言えることだが、
脱落する人って、『デスマの原因を作った人（作ったとされる人）』
である場合が、多いようだぞ。
それ以外は案外、気楽にやてるみたいよ。
まぁ、あくまでオレの周りにいる（いた）連中を
オレが客観的に見た感じでは、だけども。
557 ：仕様書無しさん：2007/04/12(木) 22:58:46
559 ：545：2007/04/12(木) 23:06:41
今日レビューで横長DBなのを叩かれて半泣きだったわ
561 ：545：2007/04/12(木) 23:23:59
え？まさか.....
562 ：仕様書無しさん：2007/04/12(木) 23:57:59
俺の知り合いのコボラもDB設計は小学3年かよ、ってレベルで
正規化とか冗長って言葉から教えてやらないとダメな感じ。
あんた何年プログラム作ってんだよ？って感じ。
もっとも専門卒で、基本情報すらもってないような奴だし、
そもそも学習能力あったら、未だにcobolで開発始めねーしな。
（銀行とか一部は知らん）
しかしまあ、進化の早いこの業界、明日は我が身なのであまりいじめない。
正規化とか冗長って言葉から教えてやらないとダメな感じ。
あんた何年プログラム作ってんだよ？って感じ。
もっとも専門卒で、基本情報すらもってないような奴だし、
そもそも学習能力あったら、未だにcobolで開発始めねーしな。
（銀行とか一部は知らん）
しかしまあ、進化の早いこの業界、明日は我が身なのであまりいじめない。
563 ：仕様書無しさん：2007/04/13(金) 22:11:18
ここ見てるやつで。
４０歳以上の平社員いる？
４０歳以上の平社員いる？
ﾉｼ
肩書きはない。
見事なまでにないｗ
でも気にしない。
肩書きはない。
見事なまでにないｗ
でも気にしない。
565 ：仕様書無しさん：2007/04/14(土) 10:38:45
>>564
で、年収はおいくら？
で、年収はおいくら？
567 ：仕様書無しさん：2007/04/14(土) 16:52:21
なんだ、
４０にしては決して多くないが、
意外ともらてるじゃねぇか。
４０にしては決して多くないが、
意外ともらてるじゃねぇか。
568 ：仕様書無しさん：2007/04/15(日) 22:16:08
>>565
お前、子ボラ？
お前、子ボラ？
569 ：545：2007/04/15(日) 22:17:35
明日、この前、叱ってやったコボラの仕様書のレビューがある。
また、苛めてやろうっと ｗ
また、苛めてやろうっと ｗ
570 ：仕様書無しさん：2007/04/15(日) 22:21:21
俺はCOBOLという言語を勉強してみた。ひょっとしたら役に立つかもしれなかったから。
俺はORACLEというDBMSを勉強した。客先がORACLEでないとダメだったから。
そして、「ダメ」がなんたるかを悟った。
俺はORACLEというDBMSを勉強した。客先がORACLEでないとダメだったから。
そして、「ダメ」がなんたるかを悟った。
>>570
コロボックルは、レコードありきだからね。
おいしいなあ。
だがしかし、業務系は遠慮したいね。
愛社精神ばかり押し付けてばかりで
知識もろくにない、社長自らのせいでコケそうになってる
日本業界内２００位ですら喜んで社員に自慢する
点取虫だけがおいしい目にあう会社には二度と関わりたくないですから。
コロボックルは、レコードありきだからね。
おいしいなあ。
だがしかし、業務系は遠慮したいね。
愛社精神ばかり押し付けてばかりで
知識もろくにない、社長自らのせいでコケそうになってる
日本業界内２００位ですら喜んで社員に自慢する
点取虫だけがおいしい目にあう会社には二度と関わりたくないですから。
573 ：仕様書無しさん：2007/04/15(日) 23:46:40
>>573
参考になった。
参考になった。
575 ：仕様書無しさん：2007/04/16(月) 19:10:37
まだ潰れるかどうかは知らんが、今、デスマ中。
先月末で辞めた先輩は、人月１２０マソ（業務委託）で今月からまた、
同じ会社に来てる。
８月から別の会社にもう内定はとってるらしい。
４ヶ月小遣い稼ぎだと。
ええなー。
目標は４ヶ月でニュービートルRSI買うことだとさ。
残業代あわせたら、１０００くらい稼げるんかもな。
ええなー。
先月末で辞めた先輩は、人月１２０マソ（業務委託）で今月からまた、
同じ会社に来てる。
８月から別の会社にもう内定はとってるらしい。
４ヶ月小遣い稼ぎだと。
ええなー。
目標は４ヶ月でニュービートルRSI買うことだとさ。
残業代あわせたら、１０００くらい稼げるんかもな。
ええなー。
576 ：545：2007/04/16(月) 21:47:26
いやー、今日のレビューも楽しかった！！
また、コボラ泣かしたった ｗ
ていうか、なんで泣くねん ｗ
あいつ、もう辞めるな ｗ
また、コボラ泣かしたった ｗ
ていうか、なんで泣くねん ｗ
あいつ、もう辞めるな ｗ
どんなかんじ？
578 ：仕様書無しさん：2007/04/16(月) 21:52:29
>>576
職場全員バカっぽいね
職場全員バカっぽいね
猫の事務所
580 ：545：2007/04/16(月) 22:36:44
漏れもそんな低レベルな職場でヌルい開発やりたいなぁ。
明日から「君」から「さん」付けに変えます
584 ：仕様書無しさん：2007/04/16(月) 23:36:42
でも今の若いコボラってある意味勝ち組だよな・・
金払いの良いでかい案件(機関系)ばかりだろうし
ライバルは減る一方だし
定年まで安泰だよな・・
だが何故か羨ましく無い
金払いの良いでかい案件(機関系)ばかりだろうし
ライバルは減る一方だし
定年まで安泰だよな・・
だが何故か羨ましく無い
585 ：545：2007/04/17(火) 00:03:42
586 ：仕様書無しさん：2007/04/17(火) 00:13:52
>>584
お前は金より『仕事できる奴と『思われる』』ことが重要ってこと？
お前は金より『仕事できる奴と『思われる』』ことが重要ってこと？
587 ：仕様書無しさん：2007/04/17(火) 00:26:39
コボラとは仕事したくないが、545みたいなのも勘弁。
589 ：仕様書無しさん：2007/04/17(火) 00:58:26
>>586
だから羨ましくは無いってば
ただ金稼げて将来に不安が無いのは世間的に勝ち組だろうなと
そんなけ
あとコボラーはプログラマーとしては酷いのが多いけど
あれはコボラーとしては出来てんじゃないの？
違うの？
だから羨ましくは無いってば
ただ金稼げて将来に不安が無いのは世間的に勝ち組だろうなと
そんなけ
あとコボラーはプログラマーとしては酷いのが多いけど
あれはコボラーとしては出来てんじゃないの？
違うの？
590 ：仕様書無しさん：2007/04/17(火) 01:02:16
俺、586だけど、545じゃないよ。
で、結局どっちがいいの？
金か
能力（があると思われること）
で、結局どっちがいいの？
金か
能力（があると思われること）
>>589
お前、質問を質問答える奴 ｗ？
お前、質問を質問答える奴 ｗ？
質問を質問で
593 ：仕様書無しさん：2007/04/17(火) 01:13:31
>>589
>>591 は
お前は、
『金のためなら目下の者に顎で使われても平気』なのか
『低賃金でも人をこき使ってデカイ面したい』のか？
と聞いていると思われ。
おっと、コレは極論だから、読み方、答え方はちゃんと考えろよ。
>>591 は
お前は、
『金のためなら目下の者に顎で使われても平気』なのか
『低賃金でも人をこき使ってデカイ面したい』のか？
と聞いていると思われ。
おっと、コレは極論だから、読み方、答え方はちゃんと考えろよ。
594 ：578：2007/04/17(火) 01:17:04
そして、俺は高収入で人をコキ使いデカイ面をする勝ち組ってワケだ。
596 ：仕様書無しさん：2007/04/17(火) 01:19:52
597 ：仕様書無しさん：2007/04/17(火) 01:24:19
コボラ乙
>>596
ほぼ、ない。
ほぼ、ない。
599 ：仕様書無しさん：2007/04/17(火) 01:25:39
>>596
１ってもういねぇんじゃね？
１ってもういねぇんじゃね？
600 ：仕様書無しさん：2007/04/17(火) 01:26:31
>>596
根拠を書けよ、禿げ。
根拠を書けよ、禿げ。
601 ：仕様書無しさん：2007/04/17(火) 01:32:12
596だが、俺はJAVA+Cだ。正規化しまくるとテーブル結合する時に
負荷がかかるじゃん。大規模なプロジェクトだとデータベース専門の頭いい人
がいるでしょ。そういう人が最初からテーブルに必要な要素を完全に定義し
切れるんなら横長でも無問題。むしろ速度が速い分いい。
負荷がかかるじゃん。大規模なプロジェクトだとデータベース専門の頭いい人
がいるでしょ。そういう人が最初からテーブルに必要な要素を完全に定義し
切れるんなら横長でも無問題。むしろ速度が速い分いい。
1レコード=1ページ は意外と速い
別に横長DBは許すよ。確かに速度的なメリットも大きいかもしれない。
だが OCCURS だけは 断る！
だが OCCURS だけは 断る！
ディスクアクセスの多いプログラムの動作時間は、
ほぼアクセスされるデータ量に比例する。
オンメモリで動かす場合でも、メインメモリへのアクセスについて同様。
冗長データを減らした方がディスクアクセスが減って高速になりそう。
それと。DBMSを作るベンダーとしては正規化して使うように作ってるはず。
バージョンアップ時には、正規化した時に速くなるように改良してゆくだろう。
ま、うだうだ考えてるより実測するのが正しいけどな。
ほぼアクセスされるデータ量に比例する。
オンメモリで動かす場合でも、メインメモリへのアクセスについて同様。
冗長データを減らした方がディスクアクセスが減って高速になりそう。
それと。DBMSを作るベンダーとしては正規化して使うように作ってるはず。
バージョンアップ時には、正規化した時に速くなるように改良してゆくだろう。
ま、うだうだ考えてるより実測するのが正しいけどな。
606 ：仕様書無しさん：2007/04/17(火) 20:41:41
>>545
年収はある意味羨ましいよ。
だけど、年とって年収が下がるのは厳しいんだぜ。
生活水準が下げられないからなぁ。
>>545は今ラクに生きてるけど、
君の年収で新人を３～４人、中途なら２～３人雇えるぜ。
寝首をかかれないように。今のうちに仲間はたくさん作っておけな。
おっと、君の年収に仲間がいるわけがないか。
ああ、これは単なるひがみだから気にするな。気にするな。
年収はある意味羨ましいよ。
だけど、年とって年収が下がるのは厳しいんだぜ。
生活水準が下げられないからなぁ。
>>545は今ラクに生きてるけど、
君の年収で新人を３～４人、中途なら２～３人雇えるぜ。
寝首をかかれないように。今のうちに仲間はたくさん作っておけな。
おっと、君の年収に仲間がいるわけがないか。
ああ、これは単なるひがみだから気にするな。気にするな。
本人含めて色々いってるけどさ、>>584は自分のプライドとかそういう意味で羨ましくないって話じゃないの？
金も栄誉も無くとも守りたいプライドとか。
俺はそういう意味なら賛同するけど。
>>596
行き過ぎるとそういう面もあるかもしれないけどな。
でもここで言う横長は効率無視で無意味に伸びきった横長だからそういう議論とは無関係じゃね。
>>607
寝首も何も545の職場全体がそうなってるんじゃないかと思うんだが。
自分一人デスマってるんじゃなく、デスマになりそうな部分を見ない振りで放置して炎上を期待してるだけなんだし。
デスマの火種を545以外全員が見落としているとは思えない。
金も栄誉も無くとも守りたいプライドとか。
俺はそういう意味なら賛同するけど。
>>596
行き過ぎるとそういう面もあるかもしれないけどな。
でもここで言う横長は効率無視で無意味に伸びきった横長だからそういう議論とは無関係じゃね。
>>607
寝首も何も545の職場全体がそうなってるんじゃないかと思うんだが。
自分一人デスマってるんじゃなく、デスマになりそうな部分を見ない振りで放置して炎上を期待してるだけなんだし。
デスマの火種を545以外全員が見落としているとは思えない。
609 ：545：2007/04/17(火) 22:37:44
ぜんぜんデスマじゃないよ。
この先も多分デスマにもならない。
この先も多分デスマにもならない。
>>607
ひがむなよ。
ひがむなよ。
じゃあ別にどんな糞DBでもいいじゃねえか
613 ：仕様書無しさん：2007/04/17(火) 22:42:21
ここは良い鬼畜スレですね。
人間って本当のことを言われると、ものすごく怒るよな。
あんまり苛るとそのうち刺されるぞ。
あんまり苛るとそのうち刺されるぞ。
とくに関西人って歴史的にチョンの血が濃いんだろ？
宅間とか Virginia Tech の二の舞
宅間とか Virginia Tech の二の舞
617 ：545：2007/04/18(水) 18:28:51
流れぶった切り&スレ違い気味ネタにつき蒙御免。
カラム名全部にテーブル名のprefix付けるのもやめて欲しい。
JOINのときに面倒くさくてしょうがない。
「COPY句ではこうやっていた」で思考停止しているのがまるわかり。
「どうしてCOPY句ではそうしてたの?」といじめてやりたい。
カラム名全部にテーブル名のprefix付けるのもやめて欲しい。
JOINのときに面倒くさくてしょうがない。
「COPY句ではこうやっていた」で思考停止しているのがまるわかり。
「どうしてCOPY句ではそうしてたの?」といじめてやりたい。
どうぞご自由に～♪
>>618
マジレスするとCOBOLはそうしないと面倒だからだろ。
あと、SQL等でもフィールドのセットのミスを低減させる意味で
テーブル名のPRIFIXをつける設計思想もある。
そういう質問すると藻前の方が思考停止君と思われるから注意汁
マジレスするとCOBOLはそうしないと面倒だからだろ。
あと、SQL等でもフィールドのセットのミスを低減させる意味で
テーブル名のPRIFIXをつける設計思想もある。
そういう質問すると藻前の方が思考停止君と思われるから注意汁
カラム名って COL001 とかだろ？冗談よしてよ
>>620 の「そういう質問」が何を指しているか解らないぜ
624 ：仕様書無しさん：2007/04/19(木) 19:03:39
>>620
スペックさらせや。
スペックさらせや。
625 ：仕様書無しさん：2007/04/19(木) 21:40:19
>>620
市ねよ。
市ねよ。
626 ：仕様書無しさん：2007/04/19(木) 21:57:58
>>620
お前の思考がとまってんだよ。
お前の思考がとまってんだよ。
627 ：仕様書無しさん：2007/04/19(木) 22:04:21
>>620
もうくんなよ。
もうくんなよ。
629 ：仕様書無しさん：2007/04/19(木) 22:32:08
630 ：仕様書無しさん：2007/04/19(木) 22:34:01
>>629
ということは、同一人物なのか？
ということは、同一人物なのか？
横長DB -> RDB -> ORMAP を経験してきたけど、
COBOLなら横長DBでも良いんじゃないかなと思う
しかし、COBOLとJavaが混在する環境や、COBOLを使わないのに横長だと辛いかもね
COBOLなら横長DBでも良いんじゃないかなと思う
しかし、COBOLとJavaが混在する環境や、COBOLを使わないのに横長だと辛いかもね
632 ：仕様書無しさん：2007/04/19(木) 22:46:45
>>631
生意気抜かす前にお前のスペック晒せや。
年齢 ：
年収 ：
最終学歴 ：
勤続年数 ：
役職(あれば)：
下請／元請 ：
派遣／非派遣：
未婚／既婚 ：
童貞／非童貞：
ｲｹﾒﾝ／ｼｹﾒﾝ ：
オタ／非オタ：
包茎／非包茎：
生意気抜かす前にお前のスペック晒せや。
年齢 ：
年収 ：
最終学歴 ：
勤続年数 ：
役職(あれば)：
下請／元請 ：
派遣／非派遣：
未婚／既婚 ：
童貞／非童貞：
ｲｹﾒﾝ／ｼｹﾒﾝ ：
オタ／非オタ：
包茎／非包茎：
633 ：仕様書無しさん：2007/04/19(木) 22:49:04
年齢 ：童貞
年収 ：童貞
最終学歴 ：童貞
勤続年数 ：童貞
役職(あれば)：童貞
下請／元請 ：童貞
派遣／非派遣：童貞
未婚／既婚 ：童貞
童貞／非童貞：童貞
ｲｹﾒﾝ／ｼｹﾒﾝ ：童貞
オタ／非オタ：童貞
包茎／非包茎：童貞
年収 ：童貞
最終学歴 ：童貞
勤続年数 ：童貞
役職(あれば)：童貞
下請／元請 ：童貞
派遣／非派遣：童貞
未婚／既婚 ：童貞
童貞／非童貞：童貞
ｲｹﾒﾝ／ｼｹﾒﾝ ：童貞
オタ／非オタ：童貞
包茎／非包茎：童貞
634 ：仕様書無しさん：2007/04/19(木) 22:49:51
>>633
じゃますんな！
はよ晒せや>>631
年齢 ：
年収 ：
最終学歴 ：
勤続年数 ：
役職(あれば)：
下請／元請 ：
派遣／非派遣：
未婚／既婚 ：
童貞／非童貞：
ｲｹﾒﾝ／ｼｹﾒﾝ ：
オタ／非オタ：
包茎／非包茎：
じゃますんな！
はよ晒せや>>631
年齢 ：
年収 ：
最終学歴 ：
勤続年数 ：
役職(あれば)：
下請／元請 ：
派遣／非派遣：
未婚／既婚 ：
童貞／非童貞：
ｲｹﾒﾝ／ｼｹﾒﾝ ：
オタ／非オタ：
包茎／非包茎：
635 ：仕様書無しさん：2007/04/19(木) 23:08:59
年齢 ：ｼｹﾒﾝ
年収 ：ｼｹﾒﾝ
最終学歴 ：ｼｹﾒﾝ
勤続年数 ：ｼｹﾒﾝ
役職(あれば)：ｼｹﾒﾝ
下請／元請 ：ｼｹﾒﾝ
派遣／非派遣：ｼｹﾒﾝ
未婚／既婚 ：ｼｹﾒﾝ
童貞／非童貞：ｼｹﾒﾝ
ｲｹﾒﾝ／ｼｹﾒﾝ ：ｼｹﾒﾝ
オタ／非オタ：ｼｹﾒﾝ
包茎／非包茎：ｼｹﾒﾝ
年収 ：ｼｹﾒﾝ
最終学歴 ：ｼｹﾒﾝ
勤続年数 ：ｼｹﾒﾝ
役職(あれば)：ｼｹﾒﾝ
下請／元請 ：ｼｹﾒﾝ
派遣／非派遣：ｼｹﾒﾝ
未婚／既婚 ：ｼｹﾒﾝ
童貞／非童貞：ｼｹﾒﾝ
ｲｹﾒﾝ／ｼｹﾒﾝ ：ｼｹﾒﾝ
オタ／非オタ：ｼｹﾒﾝ
包茎／非包茎：ｼｹﾒﾝ
年齢 ：ｼﾒｼﾞ
年収 ：ｼﾒｼﾞ
最終学歴 ：ｼﾒｼﾞ
勤続年数 ：ｼﾒｼﾞ
役職(あれば)：ｼﾒｼﾞ
下請／元請 ：ｼﾒｼﾞ
派遣／非派遣：ｼﾒｼﾞ
未婚／既婚 ：ｼﾒｼﾞ
童貞／非童貞：ｼﾒｼﾞ
ｲｹﾒﾝ／ｼｹﾒﾝ ：ｼﾒｼﾞ
オタ／非オタ：ｼﾒｼﾞ
包茎／非包茎：ｼﾒｼﾞ
年収 ：ｼﾒｼﾞ
最終学歴 ：ｼﾒｼﾞ
勤続年数 ：ｼﾒｼﾞ
役職(あれば)：ｼﾒｼﾞ
下請／元請 ：ｼﾒｼﾞ
派遣／非派遣：ｼﾒｼﾞ
未婚／既婚 ：ｼﾒｼﾞ
童貞／非童貞：ｼﾒｼﾞ
ｲｹﾒﾝ／ｼｹﾒﾝ ：ｼﾒｼﾞ
オタ／非オタ：ｼﾒｼﾞ
包茎／非包茎：ｼﾒｼﾞ
>>618-636
が全て手の込んだ自作自演に見えた俺は終わっている。
>>620のPRIFIXは思考停止しているかのような設計思想だと思うんだが…
テーブル名にPrifixつけるとかなら理解できるけど。
が全て手の込んだ自作自演に見えた俺は終わっている。
>>620のPRIFIXは思考停止しているかのような設計思想だと思うんだが…
テーブル名にPrifixつけるとかなら理解できるけど。
642 名前: It's＠名無しさん メール: sage 投稿日: 2007/04/17(火) 12:21:11
>>630
高性能だと「ダサい」というマイナスシメージで見られてしまう風情だからな。
任天堂は流れに乗って上手いとこやったよな。
_,,,......,,__
／_~ ,,...:::＿::;; ~"'ヽ
(,, '"ヾヽ i|i //^''ヽ,,)
^ :'⌒i i⌒"
| ( ﾟДﾟ) ＜ マイナスシメージ
|（ﾉ |）
| |
ヽ ＿ノ like.no.other
U"U It's a GK Quality
>>630
高性能だと「ダサい」というマイナスシメージで見られてしまう風情だからな。
任天堂は流れに乗って上手いとこやったよな。
_,,,......,,__
／_~ ,,...:::＿::;; ~"'ヽ
(,, '"ヾヽ i|i //^''ヽ,,)
^ :'⌒i i⌒"
| ( ﾟДﾟ) ＜ マイナスシメージ
|（ﾉ |）
| |
ヽ ＿ノ like.no.other
U"U It's a GK Quality
ところで Prefix なんじゃねーの？っていうのはコボラー様には突っ込んじゃいけないところなのか？w
640 ：仕様書無しさん：2007/04/20(金) 00:52:28
命名規則はこだわるところ。
しかし、こだわってる（っぽく見える）奴にカスが多いのが実際のところ。
しかし、こだわってる（っぽく見える）奴にカスが多いのが実際のところ。
641 ：仕様書無しさん：2007/04/20(金) 00:57:31
同年代では俺がほぼ最強だろ？？
年齢 ：29
年収 ：1300
最終学歴 ：旧帝大卒
勤続年数 ：7年
役職(あれば)：副部長
下請／元請 ：元請
派遣／非派遣：非派遣
未婚／既婚 ：未婚
童貞／非童貞：非童貞
ｲｹﾒﾝ／ｼｹﾒﾝ ：ｲｹﾒﾝ
オタ／非オタ：非オタ
包茎／非包茎：非包茎
年齢 ：29
年収 ：1300
最終学歴 ：旧帝大卒
勤続年数 ：7年
役職(あれば)：副部長
下請／元請 ：元請
派遣／非派遣：非派遣
未婚／既婚 ：未婚
童貞／非童貞：非童貞
ｲｹﾒﾝ／ｼｹﾒﾝ ：ｲｹﾒﾝ
オタ／非オタ：非オタ
包茎／非包茎：非包茎
>>639
ああよく最近のLinuxディストリでSendMailやQMailの代わりに入ってるMTAだろ？
ああよく最近のLinuxディストリでSendMailやQMailの代わりに入ってるMTAだろ？
コボラ様はMTAとかわかりません
>>620
マジレス? これが? 釣りでしょ、むしろ。
> COBOLはそうしないと面倒だからだろ。
・なぜそうしないと面倒なのか
・そうすることで何が面倒じゃなくなるのか
まで考えてみれば、その流儀をそのままRDBに持ち込むことが
如何に無意味であるか、自ずと分かるはず。
RDBでREPLACING **** BY $$$$.しようとか、素で考えてない?
> あと、SQL等でもフィールドのセットのミスを低減させる意味で
> テーブル名のPRIFIXをつける設計思想もある。
一見もっともそうだが、机上の空論。システムハンガリアン並みに役に立たない。
・読み込み時に混乱するなら、アドホックに適切な別名をつけてやったほうが柔軟。
・書き込み時は個々のテーブル単位なので、混乱発生の余地がない(極論だが)。
・更新可能なビューなら、そもそもビュー定義時に別名がつけられている。
・それでも混乱が起きるなら、マスタの内容をそっくりコピーして保持してるような
テーブルレイアウトからまず何とかすべきだろう。
今日の現場を知らない元請or管理職にしてみれば
よかれと思ってやってんだろうけど、こっちはいい迷惑だ。
マジレス? これが? 釣りでしょ、むしろ。
> COBOLはそうしないと面倒だからだろ。
・なぜそうしないと面倒なのか
・そうすることで何が面倒じゃなくなるのか
まで考えてみれば、その流儀をそのままRDBに持ち込むことが
如何に無意味であるか、自ずと分かるはず。
RDBでREPLACING **** BY $$$$.しようとか、素で考えてない?
> あと、SQL等でもフィールドのセットのミスを低減させる意味で
> テーブル名のPRIFIXをつける設計思想もある。
一見もっともそうだが、机上の空論。システムハンガリアン並みに役に立たない。
・読み込み時に混乱するなら、アドホックに適切な別名をつけてやったほうが柔軟。
・書き込み時は個々のテーブル単位なので、混乱発生の余地がない(極論だが)。
・更新可能なビューなら、そもそもビュー定義時に別名がつけられている。
・それでも混乱が起きるなら、マスタの内容をそっくりコピーして保持してるような
テーブルレイアウトからまず何とかすべきだろう。
今日の現場を知らない元請or管理職にしてみれば
よかれと思ってやってんだろうけど、こっちはいい迷惑だ。
>>644ってCOBOLでプログラム組んだ事あるのか？
現場を知らない机上の空論が連発しているが。
現場を知らない机上の空論が連発しているが。
年齢 ：30
年収 ：650
最終学歴 ：大学
勤続年数 ：4
役職(あれば)：PL
下請／元請 ：両方
派遣／非派遣：非
未婚／既婚 ：未
童貞／非童貞：非
ｲｹﾒﾝ／ｼｹﾒﾝ ：ｶﾌﾞｷ系が好きならｲｹ
オタ／非オタ：非
包茎／非包茎：非
だった
年収 ：650
最終学歴 ：大学
勤続年数 ：4
役職(あれば)：PL
下請／元請 ：両方
派遣／非派遣：非
未婚／既婚 ：未
童貞／非童貞：非
ｲｹﾒﾝ／ｼｹﾒﾝ ：ｶﾌﾞｷ系が好きならｲｹ
オタ／非オタ：非
包茎／非包茎：非
だった
> >>644ってCOBOLでプログラム組んだ事あるのか？
> 現場を知らない机上の空論が連発しているが。
「RDBにCOBOLの流儀を持ち込まんでくれ」って話をしてるときに
COBOLでぇ～? 机上の空論が連発～? しかも具体的な指摘ゼロ～?
なお>>644で挙げたことは、RDBなら別に机上の空論でもないと思ってるが。
> 現場を知らない机上の空論が連発しているが。
「RDBにCOBOLの流儀を持ち込まんでくれ」って話をしてるときに
COBOLでぇ～? 机上の空論が連発～? しかも具体的な指摘ゼロ～?
なお>>644で挙げたことは、RDBなら別に机上の空論でもないと思ってるが。
だからカラム名は全部COL001という風にしろよ
ねーよｗ
>>648
では>>646を書き直しておきます。
COL01: 30
COL02: 650
COL03: 大学
COL04: 4
COL05: PL
COL06: 両方
COL07: 非
COL08: 未
COL09: 非
COL10: ｶﾌﾞｷ系が好きならｲｹ
COL11: 非
COL12: 非
では>>646を書き直しておきます。
COL01: 30
COL02: 650
COL03: 大学
COL04: 4
COL05: PL
COL06: 両方
COL07: 非
COL08: 未
COL09: 非
COL10: ｶﾌﾞｷ系が好きならｲｹ
COL11: 非
COL12: 非
>>650
COL04 は2桁項目ですので0埋めしてください
COL04 は2桁項目ですので0埋めしてください
>>651
COBOLで組んだことがないと厨房…その発想はなかったわ。
むしろ出来ることならCOBOLでの業務経歴、
きれいさっぱり抹消して欲しいとすら思ってるんだが。
あんなアナクロロートル言語に関わっちまったせいで、
未だに「レガシー引きずり案件」から逃れられん。
コボラーの「常識」=RDBの非常識から解放された、きれいな案件やりたい…。
ところで「劣等感」とか「クビ」とか…最近つらいことがあったのか?
COBOLで組んだことがないと厨房…その発想はなかったわ。
むしろ出来ることならCOBOLでの業務経歴、
きれいさっぱり抹消して欲しいとすら思ってるんだが。
あんなアナクロロートル言語に関わっちまったせいで、
未だに「レガシー引きずり案件」から逃れられん。
コボラーの「常識」=RDBの非常識から解放された、きれいな案件やりたい…。
ところで「劣等感」とか「クビ」とか…最近つらいことがあったのか?
自分自身がｺﾃｺﾃのCOBOLerのクセに同族嫌悪か・・・。
底辺暮らしが長くて「漏れはもっといい仕事が出来るんだ！」と思い込んでる
哀れな無能社員は大変ですな。
底辺暮らしが長くて「漏れはもっといい仕事が出来るんだ！」と思い込んでる
哀れな無能社員は大変ですな。
＞コボラーの「常識」=RDBの非常識から解放された、きれいな案件やりたい…。
んな案件のゴロゴロあるんだが。
まあ、底辺のコーダーなんだろ。
んな案件のゴロゴロあるんだが。
まあ、底辺のコーダーなんだろ。
>>654
OracleとかDB2とかの上の方の資格でも取って転職すれば？
まあ、人間的に愚痴っぽいヤツはどこに言ってもウザがられるだろうけど。
おそらく654はいい意味で真のCOBOLerだとｵﾓ。
OracleとかDB2とかの上の方の資格でも取って転職すれば？
まあ、人間的に愚痴っぽいヤツはどこに言ってもウザがられるだろうけど。
おそらく654はいい意味で真のCOBOLerだとｵﾓ。
漏れは過去のCOBOLerの作ったシステムを、ワリと現代風にする
案件やってるけど、そんなに困難か？
むしろ２・３年前レベルのシステムを構築するだけで顧客から
感動されるので、逆に悪い気がしてくるんだが・・・。
ただ要求される知識はCOBOLやRDBだけでもダメなので、
コーダー経験だけ長くても、上司に却下されるだろうし、
レガシー人間も「やっぱCOBOLの方が楽だ」と逃げたがるだろうけど、
本気で底辺脱出したいなら、実績積めば？としか言いようが無いな。
案件やってるけど、そんなに困難か？
むしろ２・３年前レベルのシステムを構築するだけで顧客から
感動されるので、逆に悪い気がしてくるんだが・・・。
ただ要求される知識はCOBOLやRDBだけでもダメなので、
コーダー経験だけ長くても、上司に却下されるだろうし、
レガシー人間も「やっぱCOBOLの方が楽だ」と逃げたがるだろうけど、
本気で底辺脱出したいなら、実績積めば？としか言いようが無いな。
現代風って韓国風ということ？
韓国風の意味が解らんけど、Vistaにしたら動かんとかそういうのではないな。ｗ
662 ：仕様書無しさん：2007/04/21(土) 00:15:31
>>650
負け組だな
負け組だな
>>660
それってMacでも動くの？
それってMacでも動くの？
>>655-658
C系がネイティブ言語なのでご安心を。
COBOLも知っちゃってるもんで、便利に使われてこのザマよ。
愚痴はさておき本題に戻すと、脱レガシー・脱底辺だからこそ
横長テーブルやテーブル名prefix付きカラム名なんてダメだと思うんだよね。
RDB使うならRDBが活きる設計をして欲しい。
でCOBOLの流儀イラネと書いてたら、真性コボラーに思わぬ角度から粘着され
つい釣られてカミングアウト。両方触ってるからこそダメさを分かってるんだってば。
もう煽りはいいから少しは具体的なこと書いてください > 真性コボラー。
ま「きれいな案件やりたい」と言ったが、そんなに贅沢は言わない。
ただ横長テーブルやテーブル名prefix付きカラム名を採用する
レガシー人間がメンバーから外れてくれれば、それだけでいいんだ。
C系がネイティブ言語なのでご安心を。
COBOLも知っちゃってるもんで、便利に使われてこのザマよ。
愚痴はさておき本題に戻すと、脱レガシー・脱底辺だからこそ
横長テーブルやテーブル名prefix付きカラム名なんてダメだと思うんだよね。
RDB使うならRDBが活きる設計をして欲しい。
でCOBOLの流儀イラネと書いてたら、真性コボラーに思わぬ角度から粘着され
つい釣られてカミングアウト。両方触ってるからこそダメさを分かってるんだってば。
もう煽りはいいから少しは具体的なこと書いてください > 真性コボラー。
ま「きれいな案件やりたい」と言ったが、そんなに贅沢は言わない。
ただ横長テーブルやテーブル名prefix付きカラム名を採用する
レガシー人間がメンバーから外れてくれれば、それだけでいいんだ。
>現代風って韓国風ということ？
ゲンダイをヒュンデと読めばそうなるな。ってかお前ハン板の住人？
ゲンダイをヒュンデと読めばそうなるな。ってかお前ハン板の住人？
漏れは「○○が出来る」と自称するCOBOLer多いけど、
他で使えないからCOBOLの仕事やってるやつが漏れの周りではほとんどだが。
＞レガシー人間がメンバーから外れてくれれば、それだけでいいんだ。
結局レガシー底辺人間と同じレベルのエンジニアが「漏れは違う」と
言っても上から見たら同類なんだから、あきらめれば？
ＲＤＢの設計がクソならそのレビューの時にそのエンジニアに「やりなおせヴァカ」
と言えばすむ話じゃん。仕事仲間に言いたい事も言えない底辺が愚痴ってもみっともない。
他で使えないからCOBOLの仕事やってるやつが漏れの周りではほとんどだが。
＞レガシー人間がメンバーから外れてくれれば、それだけでいいんだ。
結局レガシー底辺人間と同じレベルのエンジニアが「漏れは違う」と
言っても上から見たら同類なんだから、あきらめれば？
ＲＤＢの設計がクソならそのレビューの時にそのエンジニアに「やりなおせヴァカ」
と言えばすむ話じゃん。仕事仲間に言いたい事も言えない底辺が愚痴ってもみっともない。
誤解しとるねー。
・COBOLな旧システムのリプレース等。
・新システムの開発言語自体はCOBOLではない。
・しかし設計思想はばりばりCOBOLチック。
・投入された時点でレビューは「有無に関わらず」既に終了扱い。
確かに底辺の現場だ…一度職場交換してみるか? >>666。
「やりなおせヴァカ」で時間が戻せるならそうしてるさ。
・COBOLな旧システムのリプレース等。
・新システムの開発言語自体はCOBOLではない。
・しかし設計思想はばりばりCOBOLチック。
・投入された時点でレビューは「有無に関わらず」既に終了扱い。
確かに底辺の現場だ…一度職場交換してみるか? >>666。
「やりなおせヴァカ」で時間が戻せるならそうしてるさ。
誤解も何も情報後出しで、言い訳されてもな。
底辺乙としか言えんだろ。
職場交換と言うか漏れのイメージからすると、藻前の職場では漏れは養えないだろう。
規模によるが１年に２０００万くらい出せば、漏れが最初から作り直してやってもいい。
そこらの底辺エンジニア(COBOLer)より１０人前くらいは仕事できるから。
底辺乙としか言えんだろ。
職場交換と言うか漏れのイメージからすると、藻前の職場では漏れは養えないだろう。
規模によるが１年に２０００万くらい出せば、漏れが最初から作り直してやってもいい。
そこらの底辺エンジニア(COBOLer)より１０人前くらいは仕事できるから。
あ、名前が・・・。
他スレなので気にするな。ｗ
他スレなので気にするな。ｗ
670 ：仕様書無しさん：2007/04/21(土) 11:58:17
無限ループって怖くね？
いや、たまに PIC X(2)とかワーク変数切っているくせに
PERFORMで100までまわそうとする着ぐるみ見るからさ。
CでもVBでもJavaでもいいんだが、普通は桁は“余裕”を見て型を選ぶよな？
奴らは自分で効率が良いからと桁を中途半端に切りつめた上で
敢 え て 自 分 で
無限ループに落ちいっちまうんだよな。もうあ(ry
PERFORMで100までまわそうとする着ぐるみ見るからさ。
CでもVBでもJavaでもいいんだが、普通は桁は“余裕”を見て型を選ぶよな？
奴らは自分で効率が良いからと桁を中途半端に切りつめた上で
敢 え て 自 分 で
無限ループに落ちいっちまうんだよな。もうあ(ry
676 ：仕様書無しさん：2007/04/21(土) 18:38:23
677 ：仕様書無しさん：2007/04/21(土) 18:42:09
>>676
自分アンカーを笑うレスの定番
自分アンカーを笑うレスの定番
ちゅーか
コボラってなんでどうでもいいようなことを
わけのわからん視点で分析ごっこしたがるの？
コボラってなんでどうでもいいようなことを
わけのわからん視点で分析ごっこしたがるの？
この文章からだと、>>679が、別の視点を理解できていないようにも見える。
681 ：仕様書無しさん：2007/04/22(日) 00:40:01
682 ：仕様書無しさん：2007/04/22(日) 00:42:13
客観的に見れば
682まで含めると
ダントツで682だと思うけどネ
682まで含めると
ダントツで682だと思うけどネ
意味がないとか匂わすだとか分析だとか・・・
ぶっちゃけどうでもいいから
「定番レス」に匂わせるも糞もあるんかいな
視点？アホか
挙げ句どれが意味がないとか消防のケンカか
アンタらまとめて無限ループしてこい
ttp://pc11.2ch.net/test/read.cgi/prog/1140435913/
ぶっちゃけどうでもいいから
「定番レス」に匂わせるも糞もあるんかいな
視点？アホか
挙げ句どれが意味がないとか消防のケンカか
アンタらまとめて無限ループしてこい
ttp://pc11.2ch.net/test/read.cgi/prog/1140435913/
685 ：仕様書無しさん：2007/04/22(日) 01:47:20
…は？
>>686
低能は去れ
低能は去れ
・・・・・・なにこのアホな展開
セルフアンカーひとつでこんなに熱くなれるおまえらが羨ましいわ。
691 ：仕様書無しさん：2007/04/22(日) 09:20:10
>>689
賢いお前にはわからんわ。
賢いお前にはわからんわ。
692 ：仕様書無しさん：2007/04/22(日) 09:20:46
>>690
お前もなにか熱くなれるものを探せよ！
お前もなにか熱くなれるものを探せよ！
693 ：仕様書無しさん：2007/04/22(日) 09:23:27
沖縄県の方へ（命に関わる注意事項です）
沖縄県での選挙ですが、どうか民主党だけは避けてください。県民の生命に関わる可能性があります。
民主党の最大の公約は一国二制度（※）ですが、一度「一国二制度 沖縄 三千万」等で検索をお願いします。
この際、民主党のＨＰで調べても良いです。以下の注釈↓と矛盾することは書いてないはずですから…
※一国二制度
簡単に言えば沖縄を中国と日本の共有物にし、そこに3000万人の中国人を入植させます。
（つまり沖縄人口の 96% を中国人にして、実質、沖縄を中国人の居住地とします。）
さらに「自主」の名の下、沖縄で有事が起きても自衛隊は干渉できません。
3000万人の中国人が、少数派となった130万人の日本人に何をしても、です。
そして反日教育を受けた中国人の反日感情の強さは、ほとんどの日本人の理解を超えるものです。
今回の選挙で民主党が勝った場合、「自主」「発展」を連呼しつつ段階的に進めていくことになります。
自主と言っても、自主を認めるのが「住人の96%が中国人となった」後だということに気をつけてください。
発展と言っても、新沖縄の少数派となった「少数民族日本人」の発展ではないことに気をつけてください。
沖縄県での選挙ですが、どうか民主党だけは避けてください。県民の生命に関わる可能性があります。
民主党の最大の公約は一国二制度（※）ですが、一度「一国二制度 沖縄 三千万」等で検索をお願いします。
この際、民主党のＨＰで調べても良いです。以下の注釈↓と矛盾することは書いてないはずですから…
※一国二制度
簡単に言えば沖縄を中国と日本の共有物にし、そこに3000万人の中国人を入植させます。
（つまり沖縄人口の 96% を中国人にして、実質、沖縄を中国人の居住地とします。）
さらに「自主」の名の下、沖縄で有事が起きても自衛隊は干渉できません。
3000万人の中国人が、少数派となった130万人の日本人に何をしても、です。
そして反日教育を受けた中国人の反日感情の強さは、ほとんどの日本人の理解を超えるものです。
今回の選挙で民主党が勝った場合、「自主」「発展」を連呼しつつ段階的に進めていくことになります。
自主と言っても、自主を認めるのが「住人の96%が中国人となった」後だということに気をつけてください。
発展と言っても、新沖縄の少数派となった「少数民族日本人」の発展ではないことに気をつけてください。
694 ：仕様書無しさん：2007/04/22(日) 15:00:36
そこに戻んのかよ
cobolなんて知らない俺がこのスレで分かったことは、
コボラはRDBをファイルシステムだと思ってる事。
こういう設計に出会った事もあるけど、ちょっと謎がとけたよ。
絶滅しちまえばいいのに。
コボラはRDBをファイルシステムだと思ってる事。
こういう設計に出会った事もあるけど、ちょっと謎がとけたよ。
絶滅しちまえばいいのに。
697 ：仕様書無しさん：2007/04/22(日) 16:42:45
(； ･`д･´) な、なんだってー！！ (`･д´･ ；)
699 ：仕様書無しさん：2007/04/22(日) 20:02:36
>>697
コボラ乙
コボラ乙
700 ：仕様書無しさん：2007/04/22(日) 20:40:13
ガッ _, ,_ ガッ
ガッ_, ,_ （ ･д･） _, ,_ガッ オラ！！市ねやコボラ！！
（ ･д･） Ｕ☆ミ （･д･ ）
⊂彡☆))Д´>>697☆ミ⊃ ガッ
, ,∩彡☆ ☆ミ∩, ,
（ ） ガッ （ ）
ガッ ガッ
ガッ_, ,_ （ ･д･） _, ,_ガッ オラ！！市ねやコボラ！！
（ ･д･） Ｕ☆ミ （･д･ ）
⊂彡☆))Д´>>697☆ミ⊃ ガッ
, ,∩彡☆ ☆ミ∩, ,
（ ） ガッ （ ）
ガッ ガッ
701 ：697：2007/04/22(日) 20:47:27
＞コボラはRDBをファイルシステムだと思ってる事。
に驚いただけなのに(´･ω･`)
に驚いただけなのに(´･ω･`)
コボラにとっては、むしろ「ファイルはバイトストリームである」という考え方の方が馴染めないと思う。
703 ：仕様書無しさん：2007/04/22(日) 21:51:43
>>679
そうだったのか。
>>700
ガッ _, ,_ ガッ
ガッ_, ,_ （ ･д･） _, ,_ガッ オラ！！市ねや>>700！！
（ ･д･） Ｕ☆ミ （･д･ ）
⊂彡☆))Д´>>700☆ミ⊃ ガッ
, ,∩彡☆ ☆ミ∩, ,
（ ） ガッ （ ）
ガッ ガッ
そうだったのか。
>>700
ガッ _, ,_ ガッ
ガッ_, ,_ （ ･д･） _, ,_ガッ オラ！！市ねや>>700！！
（ ･д･） Ｕ☆ミ （･д･ ）
⊂彡☆))Д´>>700☆ミ⊃ ガッ
, ,∩彡☆ ☆ミ∩, ,
（ ） ガッ （ ）
ガッ ガッ
704 ：仕様書無しさん：2007/04/22(日) 22:02:00
コボラにとっては、intが32bitでも64bitでも関係ない。
は～っ、ビットなんてオタクみたいな用語を使うなよ。
ビジネスマンなら、桁数で答えろよな。
は～っ、ビットなんてオタクみたいな用語を使うなよ。
ビジネスマンなら、桁数で答えろよな。
705 ：仕様書無しさん：2007/04/22(日) 22:35:57
もう盗聴者に囲まれて思考する事が難しいのだろうよ
>>642
誰かつっこんでやれ。 Postfix
誰かつっこんでやれ。 Postfix
KNZMORZ_FLG_1とか何なんだよわかんねーよ！変な省略すんなハゲ！
いやいや。microSD ぐらいの大きさかも知れない。
で、年末の大掃除の時に間違えて掃除機で吸い込んじゃって全滅。
で、年末の大掃除の時に間違えて掃除機で吸い込んじゃって全滅。
銀行業務自体が無くなる悪寒
今まさに横長DBを設計しようと思うんだけど良いよね？
key1 ・・・第1ブレイクキー
key2 ・・・第2ブレイクキー
key3 ・・・第3ブレイクキー
value1・・・何かの値
value2・・・予備の値
value3・・・予備の値
まあ、中間テーブルなのでしゃーないな
key1 ・・・第1ブレイクキー
key2 ・・・第2ブレイクキー
key3 ・・・第3ブレイクキー
value1・・・何かの値
value2・・・予備の値
value3・・・予備の値
まあ、中間テーブルなのでしゃーないな
714 ：仕様書無しさん：2007/04/23(月) 20:40:30
715 ：仕様書無しさん：2007/04/23(月) 20:58:47
ガッ _, ,_ ガッ
ガッ_, ,_ （ ･д･） _, ,_ガッ オラ!!市ねやコボラ!!
（ ･д･） Ｕ☆ミ （･д･ ）
⊂彡☆))Д´>>713☆ミ⊃ ガッ
, ,∩彡☆ ☆ミ∩, ,
（ ） ガッ （ ）
ガッ ガッ
ガッ_, ,_ （ ･д･） _, ,_ガッ オラ!!市ねやコボラ!!
（ ･д･） Ｕ☆ミ （･д･ ）
⊂彡☆))Д´>>713☆ミ⊃ ガッ
, ,∩彡☆ ☆ミ∩, ,
（ ） ガッ （ ）
ガッ ガッ
「ブレイクキー」
ぶち殺してやりたい単語(ワード)だな!!!
マジで殺意いだかされるよ。
死ね。氏ねじゃなくて死ね!!!＞「ブレイクキー」
ぶち殺してやりたい単語(ワード)だな!!!
マジで殺意いだかされるよ。
死ね。氏ねじゃなくて死ね!!!＞「ブレイクキー」
717 ：仕様書無しさん：2007/04/23(月) 21:18:39
ガッ _, ,_ ガッ
ガッ_, ,_ （ ･д･） _, ,_ガッ オラ!!市ねやコボラ!!
（ ･д･） Ｕ☆ミ （･д･ ）
⊂彡☆))Д´>>712☆ミ⊃ ガッ
, ,∩彡☆ ☆ミ∩, ,
（ ） ガッ （ ）
ガッ ガッ
ガッ_, ,_ （ ･д･） _, ,_ガッ オラ!!市ねやコボラ!!
（ ･д･） Ｕ☆ミ （･д･ ）
⊂彡☆))Д´>>712☆ミ⊃ ガッ
, ,∩彡☆ ☆ミ∩, ,
（ ） ガッ （ ）
ガッ ガッ
>>714
ここに至るまで誰も定義を示してくれてはいませんが。
ここに至るまで誰も定義を示してくれてはいませんが。
719 ：仕様書無しさん：2007/04/23(月) 21:39:19
>>718
カラム数じゃなくて、冗長性のことじゃまいか？
カラム数じゃなくて、冗長性のことじゃまいか？
720 ：仕様書無しさん：2007/04/23(月) 21:39:56
ガッ _, ,_ ガッ
ガッ_, ,_ （ ･д･） _, ,_ガッ オラ!!市ねやコボラ!!
（ ･д･） Ｕ☆ミ （･д･ ）
⊂彡☆))Д´>>718☆ミ⊃ ガッ
, ,∩彡☆ ☆ミ∩, ,
（ ） ガッ （ ）
ガッ ガッ
ガッ_, ,_ （ ･д･） _, ,_ガッ オラ!!市ねやコボラ!!
（ ･д･） Ｕ☆ミ （･д･ ）
⊂彡☆))Д´>>718☆ミ⊃ ガッ
, ,∩彡☆ ☆ミ∩, ,
（ ） ガッ （ ）
ガッ ガッ
今年から念願のコボラになった
こいやщ(ﾟДﾟщ)ｶﾓｰﾝ!!
こいやщ(ﾟДﾟщ)ｶﾓｰﾝ!!
722 ：仕様書無しさん：2007/04/23(月) 22:06:42
ガッ _, ,_ ガッ
ガッ_, ,_ （ ･д･） _, ,_ガッ オラ!!市ねやコボラ!!
（ ･д･） Ｕ☆ミ （･д･ ）
⊂彡☆))Д´>>721☆ミ⊃ ガッ
, ,∩彡☆ ☆ミ∩, ,
（ ） ガッ （ ）
ガッ ガッ
ガッ_, ,_ （ ･д･） _, ,_ガッ オラ!!市ねやコボラ!!
（ ･д･） Ｕ☆ミ （･д･ ）
⊂彡☆))Д´>>721☆ミ⊃ ガッ
, ,∩彡☆ ☆ミ∩, ,
（ ） ガッ （ ）
ガッ ガッ
>「ブレイクキー」
後のマッチング処理の事を考えて設計してください。
後のマッチング処理の事を考えて設計してください。
>>724
ガッ _, ,_ ガッ
ガッ_, ,_ （ ･д･） _, ,_ガッ 必死だな。コボラ。
（ ･д･） Ｕ☆ミ （･д･ ）
⊂彡☆))Д´>>724☆ミ⊃ ガッ
, ,∩彡☆ ☆ミ∩, ,
（ ） ガッ （ ）
ガッ ガッ
ガッ _, ,_ ガッ
ガッ_, ,_ （ ･д･） _, ,_ガッ 必死だな。コボラ。
（ ･д･） Ｕ☆ミ （･д･ ）
⊂彡☆))Д´>>724☆ミ⊃ ガッ
, ,∩彡☆ ☆ミ∩, ,
（ ） ガッ （ ）
ガッ ガッ
「ブレイクキー」なるものをこのスレではじめて知った。
ぐぐってみたけど、こいつらとは一緒に生きていけないことも知った。
ぐぐってみたけど、こいつらとは一緒に生きていけないことも知った。
>>724 は「冗長」って言葉の意味を知らないんだな ｗ
ガッ _, ,_ ガッ
ガッ_, ,_ （ ･д･） _, ,_ガッ 必死だな。コボラ。
（ ･д･） Ｕ☆ミ （･д･ ）
⊂彡☆))Д´>>724☆ミ⊃ ガッ
, ,∩彡☆ ☆ミ∩, ,
（ ） ガッ （ ）
ガッ ガッ
ガッ_, ,_ （ ･д･） _, ,_ガッ 必死だな。コボラ。
（ ･д･） Ｕ☆ミ （･д･ ）
⊂彡☆))Д´>>724☆ミ⊃ ガッ
, ,∩彡☆ ☆ミ∩, ,
（ ） ガッ （ ）
ガッ ガッ
「ある項目をキーとして、キーが変わるまで集計したり一定の処理をしたりするプログラム。
これはプログラミングの基本中の基本でしょう。」
ﾊｧ?
これはプログラミングの基本中の基本でしょう。」
ﾊｧ?
GROUP BY
>>729
RDBの登場によってそういうのは不要になった、
ってことをコボラ連中にきちんと教えてあげる人が少ないんだろ。
技術の進歩に伴って常識が変わっていく、
ということ自体案外知られてないのかも。
RDBの登場によってそういうのは不要になった、
ってことをコボラ連中にきちんと教えてあげる人が少ないんだろ。
技術の進歩に伴って常識が変わっていく、
ということ自体案外知られてないのかも。
以前見たOracleのプロシージャで見た"キーがブレークしたら"という謎コメントは
そういう意味だったのか！！！
そういう意味だったのか！！！
>>725
煽る以外の能力がないのか間抜け。
>>730 が指摘してるが、ふつー GROUP BY で集約するもんだ。
>>727
お前は正規化も知らなそうだな。いやなんとなく。
>>733
たまーにそういう処理が必要になることもあるけどね。
RDB が Oracle でも、客の予算の都合で Enterprise Edition じゃなかったり
すると集計関数が使えないとか、そーゆー理由で。
煽る以外の能力がないのか間抜け。
>>730 が指摘してるが、ふつー GROUP BY で集約するもんだ。
>>727
お前は正規化も知らなそうだな。いやなんとなく。
>>733
たまーにそういう処理が必要になることもあるけどね。
RDB が Oracle でも、客の予算の都合で Enterprise Edition じゃなかったり
すると集計関数が使えないとか、そーゆー理由で。
RDBも良いが、たまにアイサムファイルっぽくアクセスしたくなる時は有る。
うっとうしい処理とかをストアドでキーブレークを使って書いたことはあるけど。
わざわざブレークキーなるものをテーブルに設計する真似はコボラならではだろう。
わざわざブレークキーなるものをテーブルに設計する真似はコボラならではだろう。
ガッ _, ,_ ガッ
ガッ_, ,_ （ ･д･） _, ,_ガッ
（ ･д･） Ｕ☆ミ （･д･ ） 乗ってきたな ｗ
⊂彡☆))Д´>>734☆ミ⊃ ガッ こいや、コボラ！！
, ,∩彡☆ ☆ミ∩, ,
（ ） ガッ （ ）
ガッ ガッ
ガッ_, ,_ （ ･д･） _, ,_ガッ
（ ･д･） Ｕ☆ミ （･д･ ） 乗ってきたな ｗ
⊂彡☆))Д´>>734☆ミ⊃ ガッ こいや、コボラ！！
, ,∩彡☆ ☆ミ∩, ,
（ ） ガッ （ ）
ガッ ガッ
AAで必死に自己アピールを繰り返すヴビ厨(絶滅危惧種)ｗ
ガッ _, ,_ ガッ
ガッ_, ,_ （ ･д･） _, ,_ガッ
（ ･д･） Ｕ☆ミ （･д･ ）
⊂彡☆))Д´>>739☆ミ⊃ ガッ オラ！！絶滅せぇや、コボラ！！
, ,∩彡☆ ☆ミ∩, ,
（ ） ガッ （ ）
ガッ ガッ
ガッ_, ,_ （ ･д･） _, ,_ガッ
（ ･д･） Ｕ☆ミ （･д･ ）
⊂彡☆))Д´>>739☆ミ⊃ ガッ オラ！！絶滅せぇや、コボラ！！
, ,∩彡☆ ☆ミ∩, ,
（ ） ガッ （ ）
ガッ ガッ
Accessで帳票作るときなんか、たまにブレークキーが必要だったり･･･
ガッ _, ,_ ガッ
ガッ_, ,_ （ ･д･） _, ,_ガッ
（ ･д･） Ｕ☆ミ （･д･ ）
⊂彡☆))Д´>>741☆ミ⊃ ガッ オラ！！絶滅せぇや、ブビ！！
, ,∩彡☆ ☆ミ∩, ,
（ ） ガッ （ ）
ガッ ガッ
Access馬鹿にすんなや！ お手軽帳票ミドルウェアとしては微妙に優秀だぞ！
744 ：仕様書無しさん：2007/04/24(火) 22:06:26
ガッ _, ,_ ガッ
ガッ_, ,_ （ ･д･） _, ,_ガッ
（ ･д･） Ｕ☆ミ （･д･ ）
⊂彡☆))Д´>>742☆ミ⊃ ガッ なんやとオラ！！やんのか！？コボラ！！
, ,∩彡☆ ☆ミ∩, ,
（ ） ガッ （ ）
ガッ ガッ
ガッ_, ,_ （ ･д･） _, ,_ガッ
（ ･д･） Ｕ☆ミ （･д･ ）
⊂彡☆))Д´>>742☆ミ⊃ ガッ なんやとオラ！！やんのか！？コボラ！！
, ,∩彡☆ ☆ミ∩, ,
（ ） ガッ （ ）
ガッ ガッ
>>743
おまいそれ十分馬鹿にしてないか？
キーブレークでググってソースを少し見てみた。
これが初めて見るCOBOLのソースだった。
メモ帳のコピペ/置換でファイル一覧からバッチファイルを作る作業を思い出した。
なんていうか、枡を傾けて1/4量るとか砂時計二つで時間を計るとかそういう作業を彷彿とさせてくれるソースですね…。
桜は散れど春真盛り
おまいそれ十分馬鹿にしてないか？
キーブレークでググってソースを少し見てみた。
これが初めて見るCOBOLのソースだった。
メモ帳のコピペ/置換でファイル一覧からバッチファイルを作る作業を思い出した。
なんていうか、枡を傾けて1/4量るとか砂時計二つで時間を計るとかそういう作業を彷彿とさせてくれるソースですね…。
桜は散れど春真盛り
自分もキーブレークでググってみてみた。
やっぱCOBOLよりもRPGは美しいな
ただ今では触る気も起きんが。ｗ
やっぱCOBOLよりもRPGは美しいな
ただ今では触る気も起きんが。ｗ
747 ：仕様書無しさん：2007/04/25(水) 00:10:19
ガッ _, ,_ ガッ
ガッ_, ,_ （ ･д･） _, ,_ガッ
（ ･д･） Ｕ☆ミ （･д･ ）
⊂彡☆))Д´>>745☆ミ⊃ ガッ
, ,∩彡☆ ☆ミ∩, ,
（ ） ガッ （ ）
ガッ ガッ
ガッ_, ,_ （ ･д･） _, ,_ガッ
（ ･д･） Ｕ☆ミ （･д･ ）
⊂彡☆))Д´>>745☆ミ⊃ ガッ
, ,∩彡☆ ☆ミ∩, ,
（ ） ガッ （ ）
ガッ ガッ
コボルのPGでキーブレイクの是非を論じてもしょうがないべ。
問題は、SELECT SUM(･･･ なら一発ですむ処理を、延々と1レコード毎足し算、
キーが変わったら云々･･･しようとする連中にいかにRDBのメリットを素直に
享受してもらうかじゃ。
その手の人たちが去った後にメンテを請け負う羽目になるのは我々じゃ。
問題は、SELECT SUM(･･･ なら一発ですむ処理を、延々と1レコード毎足し算、
キーが変わったら云々･･･しようとする連中にいかにRDBのメリットを素直に
享受してもらうかじゃ。
その手の人たちが去った後にメンテを請け負う羽目になるのは我々じゃ。
マジレスするとSUM云々はRDBと言うかRDBMSの機能だ。
COBOLerは自前でRDBMSを実装しているんだ。
凄いじゃないか！
無駄な努力だけどなｗ
COBOLerは自前でRDBMSを実装しているんだ。
凄いじゃないか！
無駄な努力だけどなｗ
そして行きつくところは>>508
751 ：仕様書無しさん：2007/04/25(水) 21:42:00
ガッ _, ,_ ガッ
ガッ_, ,_ （ ･д･） _, ,_ガッ
（ ･д･） Ｕ☆ミ （･д･ ）
⊂彡☆))Д´>>508☆ミ⊃ ガッ
, ,∩彡☆ ☆ミ∩, ,
（ ） ガッ （ ）
ガッ ガッ
ガッ_, ,_ （ ･д･） _, ,_ガッ
（ ･д･） Ｕ☆ミ （･д･ ）
⊂彡☆))Д´>>508☆ミ⊃ ガッ
, ,∩彡☆ ☆ミ∩, ,
（ ） ガッ （ ）
ガッ ガッ
READ命令じゃなくてSELECT文使ってくれよとは思うな。
オープン系を敵視してるみたいで、
汎用機は安定してるって繰り返して主張して自分のポストを死守してるのけ？
オープン系を敵視してるみたいで、
汎用機は安定してるって繰り返して主張して自分のポストを死守してるのけ？
まあ、実際のところ、COBOLerが４，５日かけてコーティングするところを
オープン系の人間だとサクサクと１，２日で仕上げるからなぁ。
#タマに例外あるが
COBOLerは現実から目を背けるに必死なんだろう。
オープン系の人間だとサクサクと１，２日で仕上げるからなぁ。
#タマに例外あるが
COBOLerは現実から目を背けるに必死なんだろう。
SELECT条件ひとつだけでDBからロードしたファイルを
ユーティリティ使っていろいろ抽出＆ソートして処理・・・・・・・・・
ユーティリティ使っていろいろ抽出＆ソートして処理・・・・・・・・・
>>726
俺も初めて見た。
これって group by で出来るよな? a がキーで b が値でキーごとに b の
合計したいなら select a, sum(b) from x group by a; のような。
俺も初めて見た。
これって group by で出来るよな? a がキーで b が値でキーごとに b の
合計したいなら select a, sum(b) from x group by a; のような。
Google で「ブレイクキー」で検索するとこれがトップに出てﾜﾗﾀ。
http://www.sophia-it.com/content/%E3%83%96%E3%83%AC%E3%83%BC%E3%82%AF%E3%82%AD%E3%83%BC
ブレークキー
【英】break key
ブレークキーとは、キーボードにおいて[Break]と書かれたキーのことである。
実行中のプログラムを中止するために利用されたり、あるいは通信ソフトで
ブレーク信号を送出するために利用されたりする。動作はソフトウェアによって
異なる。
http://www.sophia-it.com/content/%E3%83%96%E3%83%AC%E3%83%BC%E3%82%AF%E3%82%AD%E3%83%BC
ブレークキー
【英】break key
ブレークキーとは、キーボードにおいて[Break]と書かれたキーのことである。
実行中のプログラムを中止するために利用されたり、あるいは通信ソフトで
ブレーク信号を送出するために利用されたりする。動作はソフトウェアによって
異なる。
>>754
DBをただのデータストレージとして使うのか? もったいない。
DBをただのデータストレージとして使うのか? もったいない。
758 ：仕様書無しさん：2007/04/26(木) 10:19:07
Accessの帳票って、SQL(苦エリー)作って所望のレコード列が得られたら
あとは帳票ウィザードでひな形作ってレイアウト調整で終わりだ＞一般タイプ
集計ブレイクで複数集計値を出したいときなどは帳票側にコード埋め込む事も
有るけど、明細部で加算して集計部で印字＆クリアくらいだったと思う。
少なくともCOBOLとかで見るキーブレイク処理とは大きく異なる気がする。
あとは帳票ウィザードでひな形作ってレイアウト調整で終わりだ＞一般タイプ
集計ブレイクで複数集計値を出したいときなどは帳票側にコード埋め込む事も
有るけど、明細部で加算して集計部で印字＆クリアくらいだったと思う。
少なくともCOBOLとかで見るキーブレイク処理とは大きく異なる気がする。
知ってても実戦での使い方がわからないとゆーか
そういう発想ができないようですが
そういう発想ができないようですが
集計(等)はプログラムでするという固定観念があるんだろうね。
つまり、スカラー、行、列、表関数を作りまくれって事FA
まー、orがダメって事はUNION使えって事かなぁ。
まー、orがダメって事はUNION使えって事かなぁ。
開発規約は理解できない構文/機能を制限するのではなく、冗長性を制限しつつも統一性を持たせる為の物じゃないのか？
バグがあるから使用禁止ってわけでもあるまいに。
バグがあるから使用禁止ってわけでもあるまいに。
よく分からんし勉強もする気ないコボラーにとって
技術革新は迷惑この上無いってことだな。
技術革新は迷惑この上無いってことだな。
そういう思想の果てが∑計画だったのかねぇ…。
古い言語は開発規約はある意味いるような気がするが、
RDBのSQLだったらSQL99くらいで止めとけ、って規約くらいだろ。
MARGE使うな、とかか。
#コレSQL99にあったっけ？
RDBのSQLだったらSQL99くらいで止めとけ、って規約くらいだろ。
MARGE使うな、とかか。
#コレSQL99にあったっけ？
770 ：仕様書無しさん：2007/04/26(木) 22:49:32
>>765
INDEX使えないことがあるからかな。(OR禁)
そのためにUNION使うってのは良くある手法。
ORDER BY はクライアントでソートしたほうが速い。ただし実装はマン独裁。
AND 一回のみだけは理解不能。
INDEX使えないことがあるからかな。(OR禁)
そのためにUNION使うってのは良くある手法。
ORDER BY はクライアントでソートしたほうが速い。ただし実装はマン独裁。
AND 一回のみだけは理解不能。
771 ：仕様書無しさん：2007/04/26(木) 22:50:59
ガッ _, ,_ ガッ
ガッ_, ,_ （ ･д･） _, ,_ガッ オラ！！市ねや！！お前の言ってること意味不明！！
（ ･д･） Ｕ☆ミ （･д･ ） 具体的に！！
⊂彡☆))Д´>>766☆ミ⊃ ガッ
, ,∩彡☆ ☆ミ∩, ,
（ ） ガッ （ ）
ガッ ガッ
ガッ_, ,_ （ ･д･） _, ,_ガッ オラ！！市ねや！！お前の言ってること意味不明！！
（ ･д･） Ｕ☆ミ （･д･ ） 具体的に！！
⊂彡☆))Д´>>766☆ミ⊃ ガッ
, ,∩彡☆ ☆ミ∩, ,
（ ） ガッ （ ）
ガッ ガッ
>>770
さすがに今時の商用RDBではorでインデックス使われないからって
UNION使うと速度が出るって事はないだろう・・・。
たまにクライアントでした方が早いのは無くもないが、
クエリもキャッシングしているので、複数人が利用する場合は、
素直にRDBMSにお任せした方がパフォーマンス出るし。
さすがに今時の商用RDBではorでインデックス使われないからって
UNION使うと速度が出るって事はないだろう・・・。
たまにクライアントでした方が早いのは無くもないが、
クエリもキャッシングしているので、複数人が利用する場合は、
素直にRDBMSにお任せした方がパフォーマンス出るし。
たぶん、ディスクの容量が4Gとかそういう時代のRDBの知恵なんじゃねーのか？
その時代から頭の中身が進歩していないんだろう。
その時代から頭の中身が進歩していないんだろう。
774 ：仕様書無しさん：2007/04/26(木) 23:39:36
ガッ _, ,_ ガッ
ガッ_, ,_ （ ･д･） _, ,_ガッ オラ！！市ねや！！RDBかぶれコボラ！！
（ ･д･） Ｕ☆ミ （･д･ ）
⊂彡☆))Д´>>770☆ミ⊃ ガッ
, ,∩彡☆ ☆ミ∩, ,
（ ） ガッ （ ）
ガッ ガッ
ガッ_, ,_ （ ･д･） _, ,_ガッ オラ！！市ねや！！RDBかぶれコボラ！！
（ ･д･） Ｕ☆ミ （･д･ ）
⊂彡☆))Д´>>770☆ミ⊃ ガッ
, ,∩彡☆ ☆ミ∩, ,
（ ） ガッ （ ）
ガッ ガッ
775 ：仕様書無しさん：2007/04/27(金) 00:21:30
使用するSQL文に制限を加える件について、みなさん的外れな論議をされているようですね。
皆さんが大きく考え方を誤っているのは、技術的見地で考えている点です。
これは、絶滅危惧種であるコボラーを保護するための施策です。
日本でも米の輸入を制限したり、革製品に高率関税をかけたりしているでしょ。
そうすることによって、時代から取り残された人にも仕事を分け与え、
労働市場の需給ギャップが開くことを阻止しているのです。
つまり、使用するSQL文に制限を加えることは、
高度な政治的判断によるものなので、エンジニアが議論する話題ではありません。
皆さんが大きく考え方を誤っているのは、技術的見地で考えている点です。
これは、絶滅危惧種であるコボラーを保護するための施策です。
日本でも米の輸入を制限したり、革製品に高率関税をかけたりしているでしょ。
そうすることによって、時代から取り残された人にも仕事を分け与え、
労働市場の需給ギャップが開くことを阻止しているのです。
つまり、使用するSQL文に制限を加えることは、
高度な政治的判断によるものなので、エンジニアが議論する話題ではありません。
>>766
甘い。
「メンバーに理解出来ないことすんの禁止」 (ヘタすっと
「リーダー個人が理解出来ないことすんの禁止」) な規約は実在する。
>>770
>ORDER BY はクライアントでソートしたほうが速い。
問い合わせ結果を全部取ってくる気なら、そうだろうな。
甘い。
「メンバーに理解出来ないことすんの禁止」 (ヘタすっと
「リーダー個人が理解出来ないことすんの禁止」) な規約は実在する。
>>770
>ORDER BY はクライアントでソートしたほうが速い。
問い合わせ結果を全部取ってくる気なら、そうだろうな。
>「メンバーに理解出来ないことすんの禁止」
新人が一人でもいたらそいつに合わせる？
新人が一人でもいたらそいつに合わせる？
>777
×「メンバーに理解できない」
○「ベテラン（という肩書の老害）に理解できない」
×「メンバーに理解できない」
○「ベテラン（という肩書の老害）に理解できない」
一般的でいいから・・・・・という事で性能指標書いたら
「そんなの（ｵﾚが）聞いたことない」とか言って却下する奴は存在するｗ
「そんなの（ｵﾚが）聞いたことない」とか言って却下する奴は存在するｗ
781 ：仕様書無しさん：2007/04/28(土) 23:06:28
ガッ _, ,_ ガッ
ガッ_, ,_ （ ･д･） _, ,_ガッ ビッグボーナス入りました！！
（ ･д･） Ｕ☆ミ （･д･ ）
⊂彡☆))Д´>>777☆ミ⊃ ガッ
, ,∩彡☆ ☆ミ∩, ,
（ ） ガッ （ ）
ガッ ガッ
ガッ_, ,_ （ ･д･） _, ,_ガッ ビッグボーナス入りました！！
（ ･д･） Ｕ☆ミ （･д･ ）
⊂彡☆))Д´>>777☆ミ⊃ ガッ
, ,∩彡☆ ☆ミ∩, ,
（ ） ガッ （ ）
ガッ ガッ
COBOLという言語自体は誰にでも分かる簡単なものだからいいとして、
汎用機の扱いやコボラの扱いに非常に困る。
今までオープン系でやってきた俺には理解に苦しむ人種の集まり、
話していても外人と話しているかのような錯覚すら覚えるな。
汎用機の扱いやコボラの扱いに非常に困る。
今までオープン系でやってきた俺には理解に苦しむ人種の集まり、
話していても外人と話しているかのような錯覚すら覚えるな。
783 ：仕様書無しさん：2007/04/28(土) 23:45:55
>>782
ガッ _, ,_ ガッ
ガッ_, ,_ （ ･д･） _, ,_ガッ
（ ･д･） Ｕ☆ミ （･д･ ）
⊂彡☆))Д´☆ミ⊃ ガッ
, ,∩彡☆ ☆ミ∩, ,
（ ） ガッ （ ）
ガッ ガッ
ガッ _, ,_ ガッ
ガッ_, ,_ （ ･д･） _, ,_ガッ
（ ･д･） Ｕ☆ミ （･д･ ）
⊂彡☆))Д´☆ミ⊃ ガッ
, ,∩彡☆ ☆ミ∩, ,
（ ） ガッ （ ）
ガッ ガッ
784 ：仕様書無しさん：2007/04/29(日) 00:00:47
>>758
ヘッダ
明細A
明細B
フッタ
みたいな帳票があって、
「明細Aか明細Bのいずれかが10行を超えるか、宛先が変れば改ページ」
みたいなややこしい改ページ条件があったりすると、ブレークキーを
含んだワークテーブルがあった方が楽なの。
ヘッダ
明細A
明細B
フッタ
みたいな帳票があって、
「明細Aか明細Bのいずれかが10行を超えるか、宛先が変れば改ページ」
みたいなややこしい改ページ条件があったりすると、ブレークキーを
含んだワークテーブルがあった方が楽なの。
786 ：仕様書無しさん：2007/04/30(月) 21:53:51
>>785
ガッ _, ,_ ガッ
ガッ_, ,_ （ ･д･） _, ,_ガッ
（ ･д･） Ｕ☆ミ （･д･ ）
⊂彡☆))Д´☆ミ⊃ ガッ
, ,∩彡☆ ☆ミ∩, ,
（ ） ガッ （ ）
ガッ ガッ
ガッ _, ,_ ガッ
ガッ_, ,_ （ ･д･） _, ,_ガッ
（ ･д･） Ｕ☆ミ （･д･ ）
⊂彡☆))Д´☆ミ⊃ ガッ
, ,∩彡☆ ☆ミ∩, ,
（ ） ガッ （ ）
ガッ ガッ
技術革新なんて幻想。
バグだらけでまともにうごかないJavaより
バグ数0で開発できるCOBOLの方がずっといい。
バグだらけでまともにうごかないJavaより
バグ数0で開発できるCOBOLの方がずっといい。
COBOLでバグ0とかｗｗｗおまｗｗｗ
COBOLは別に悪くないだろ。過去の言語だが...。
悪いのはコボラーだよ。それも未だに生きている奴な。
悪いのはコボラーだよ。それも未だに生きている奴な。
791 ：仕様書無しさん：2007/05/01(火) 18:15:10
コボルは悪くない。
コボラとはコボルをやってた人という意味ではありません。
コボラとは
昔、コボルをやっていたが
RDBやオブジェクト指向を
理解できない輩の蔑称である。
コボラとはコボルをやってた人という意味ではありません。
コボラとは
昔、コボルをやっていたが
RDBやオブジェクト指向を
理解できない輩の蔑称である。
＞バグ数0で開発できるCOBOLの方がずっといい。
きっとバグを「仕様です」と言い切るアフォだろ。
まあ、COBOLerに限らず存在するけどサ
きっとバグを「仕様です」と言い切るアフォだろ。
まあ、COBOLerに限らず存在するけどサ
プログラム書く以上、ハードウェアのバグも存在程度は考慮できないと…。
それでもバグ0とかそれどんな物質で作られてるんだ。
それでもバグ0とかそれどんな物質で作られてるんだ。
> バグだらけでまともにうごかないJavaより
> バグ数0で開発できるCOBOLの方がずっといい。
浮動小数点数を100とかで割ったときに
端数がキレイにならないのを
バグだバグだと騒いでそうな悪寒…。
> バグ数0で開発できるCOBOLの方がずっといい。
浮動小数点数を100とかで割ったときに
端数がキレイにならないのを
バグだバグだと騒いでそうな悪寒…。
勘定系における専用言語なら“通貨型”はあたりまえ。
何が馬鹿かって金額とかをJavaとかCの標準型変数で実装する奴。
Javaだろうが、C/C++だろうが、通貨を扱いたければ
それ専用の型を使うなり作るなりするだろ。
何が馬鹿かって金額とかをJavaとかCの標準型変数で実装する奴。
Javaだろうが、C/C++だろうが、通貨を扱いたければ
それ専用の型を使うなり作るなりするだろ。
どーでもいいが、漏れの知っている金融機関の勘定系では
ほとんど整数ばっかりだったな。
小数点以下は100倍して扱うとか。
漏れは中間処理のDB鯖はBIGINTにしちゃったよ。
とは言え、金融機関って浮動小数点は使わんけどなぁ。
固定少数点ばっかだな。
利率とかもDECIMAL(9,7)って感じだし。
ほとんど整数ばっかりだったな。
小数点以下は100倍して扱うとか。
漏れは中間処理のDB鯖はBIGINTにしちゃったよ。
とは言え、金融機関って浮動小数点は使わんけどなぁ。
固定少数点ばっかだな。
利率とかもDECIMAL(9,7)って感じだし。
>>795
int
int
32bit(int)じゃ足らない。
64bit(long int)ならまぁ何とかなる。
64bit(long int)ならまぁ何とかなる。
俺の家計簿は short で十分。
>799
-32768～32767…？
-32768～32767…？
801 ：仕様書無しさん：2007/05/02(水) 14:44:55
>>801 は金の出入りを万単位でしか把握していないブルジョワジー。
CプログラマーはByteがお好き！
804 ：仕様書無しさん：2007/05/03(木) 03:36:40
>>801
おれは unsigned char だから同じだね。
おれは unsigned char だから同じだね。
805 ：仕様書無しさん：2007/05/05(土) 16:20:38
>>802
まて、年収127万円のどこがブルジョワジー？
まて、年収127万円のどこがブルジョワジー？
806 ：仕様書無しさん：2007/05/05(土) 16:35:32
ブルジョアは年単位の集計なんかしない
807 ：仕様書無しさん：2007/05/05(土) 22:36:30
日付にDate型を使わず、NUMBER(8,0)とかChar(8)にしていることがよくあるが、
これはコボラのDB設計で認めてもよい部分かともおもう。
これはコボラのDB設計で認めてもよい部分かともおもう。
>>804
年収２５５万？
年収２５５万？
809 ：仕様書無しさん：2007/05/05(土) 22:46:59
>>807
(； ･`д･´) な、なんだってー！！ (`･д´･ ；)
(； ･`д･´) な、なんだってー！！ (`･д´･ ；)
COBOLerは日付にDate型を使わないのではなく、存在を知らないと思う。
マジで。
マジで。
>810
仮に指摘したとしてもプログラムで扱えないとか無茶な反論しそうだな
仮に指摘したとしてもプログラムで扱えないとか無茶な反論しそうだな
日付型だと10byteで文字型だと8byteで済むじゃん！DBの容量節約じゃん！
とか嬉しそうにいいそうだな。＞COBOLer
まあ解らんでもない理屈だが・・・。
とか嬉しそうにいいそうだな。＞COBOLer
まあ解らんでもない理屈だが・・・。
>>812
OracleのDateは7byteじゃなかったっけな。
もっととんでもないのは、「和暦の文字列型なら7byte」とのたまうことじゃないかと。
ホストから送られてくる日付に和暦が多いんだが、大元からその形式で持ってるんだろうな・・・
OracleのDateは7byteじゃなかったっけな。
もっととんでもないのは、「和暦の文字列型なら7byte」とのたまうことじゃないかと。
ホストから送られてくる日付に和暦が多いんだが、大元からその形式で持ってるんだろうな・・・
もともと昔は西暦は６桁な風習が多くあったからなぁ。(900505とか)
2000年問題以前の時はそういうのが普通な感があったし。
Dateが10byteなのはDB2だな。
とはいえ'S621201'とか格納されてるのは確かに珍しくなかったような・・・。
あの頃はCOBOLerが悪いというか日本がああいうシステムなんだろうけど。
2000年問題以前の時はそういうのが普通な感があったし。
Dateが10byteなのはDB2だな。
とはいえ'S621201'とか格納されてるのは確かに珍しくなかったような・・・。
あの頃はCOBOLerが悪いというか日本がああいうシステムなんだろうけど。
奴らは 00000000 とか 99999999 (何れも西暦年月日) という
特殊な意味の日付を扱いたいが故にNUMBER(8,0)とかChar(8)
という設計をするだけ。
普通に考えれば意味のない日付(つか終端判断条件)なんだけどな。
特殊な意味の日付を扱いたいが故にNUMBER(8,0)とかChar(8)
という設計をするだけ。
普通に考えれば意味のない日付(つか終端判断条件)なんだけどな。
ガッの意味が分かってないでやってんのか、釣なのか。
ほんとなんつーか、ただ知ってるだけっつーか、浅はかっつーか。
日付型？インデックス検索効くのか？
ISNULL,ISNOTNULL,<>,!=,NOTLIKEは816が言ってるよーにインデックス検索は効かねーぜ、効かないって事は全件検索な訳だ。
だから' 'とか0にする
それとだ、ブレークキーだが、
LIKE %aiueoとかLIKE%aiueoとかやっても、実質LIKE *とかわらねー。
要は中間一致検索、後方一致検索は無理って話になる。
だから、年月日とか月集計とか欲しい場合を考えて、大分類、中分類、小分類、ブレークキーっていうのか？が要る訳だ。
コボラーのジョーシキっつーか、ノーミソついとんのかい。
ほんとなんつーか、ただ知ってるだけっつーか、浅はかっつーか。
日付型？インデックス検索効くのか？
ISNULL,ISNOTNULL,<>,!=,NOTLIKEは816が言ってるよーにインデックス検索は効かねーぜ、効かないって事は全件検索な訳だ。
だから' 'とか0にする
それとだ、ブレークキーだが、
LIKE %aiueoとかLIKE%aiueoとかやっても、実質LIKE *とかわらねー。
要は中間一致検索、後方一致検索は無理って話になる。
だから、年月日とか月集計とか欲しい場合を考えて、大分類、中分類、小分類、ブレークキーっていうのか？が要る訳だ。
コボラーのジョーシキっつーか、ノーミソついとんのかい。
>>817
COBOLで前方一致、中間一致、後方一致のやり方分かる？
COBOLで前方一致、中間一致、後方一致のやり方分かる？
819 ：仕様書無しさん：2007/05/06(日) 11:34:27
>>815
2200/01/01 とか 1800/01/01 とかを未入力扱いにするよりはマシだと思われ。
また、YMDだけ必要なところに堂々とSYSDATE そのままぶち込む馬鹿はこれでいなくなるよ。
2200/01/01 とか 1800/01/01 とかを未入力扱いにするよりはマシだと思われ。
また、YMDだけ必要なところに堂々とSYSDATE そのままぶち込む馬鹿はこれでいなくなるよ。
00000000と99999999とかの事情はわからんでもないが、
日付でインデックス効くのか？的な議論をするなら、
日付にNOT NULL制約つけとけよ、って気ガス。
どーせCOBOLerって全件検索と言うかマスタは全件読み込みってノリが
あるから、そういうRDBの作法(?)みたいなのは無視して生きてると思う。
日付でインデックス効くのか？的な議論をするなら、
日付にNOT NULL制約つけとけよ、って気ガス。
どーせCOBOLerって全件検索と言うかマスタは全件読み込みってノリが
あるから、そういうRDBの作法(?)みたいなのは無視して生きてると思う。
いや、NULLの代わりに9999/12/31とかを設定する件についての議論なんだが
＞マスタは全件読み込みってノリがあるから
は？何のためにマスタ表とトランザクション表を分けてんだよ。
マスタ表はめったなことじゃ変更なしの表として分離して、
読み込み専用として(共有ロック)分けてあるから、マスタ表はいくら読み込んでもコストかからず、
絞込みにより、更にトランザクション表のコスト、JOINのコストが軽減されるんじゃねーか
は？何のためにマスタ表とトランザクション表を分けてんだよ。
マスタ表はめったなことじゃ変更なしの表として分離して、
読み込み専用として(共有ロック)分けてあるから、マスタ表はいくら読み込んでもコストかからず、
絞込みにより、更にトランザクション表のコスト、JOINのコストが軽減されるんじゃねーか
ああ、ｽﾏｿ。
漏れの周りのCOBOLerはテーブル全てを「マスタ」と呼んでいるので
ああ書いた。
んでも、漏れの周りのCOBOLerってロックの概念しらねーんだけど。
ついでにインデックスの効率的な使い方も知らん。
そもそもテーブルのカラムは全てnull可になってるし。
漏れの周りのCOBOLerはテーブル全てを「マスタ」と呼んでいるので
ああ書いた。
んでも、漏れの周りのCOBOLerってロックの概念しらねーんだけど。
ついでにインデックスの効率的な使い方も知らん。
そもそもテーブルのカラムは全てnull可になってるし。
>>820
>>日付でインデックス効くのか？的な議論をするなら、
>>日付にNOT NULL制約つけとけよ、って気ガス。
インデックスを効かすために、DB上NULL値を許さず（システム上は許す）、
さらに、2200/12/31 や 1800/01/01 を擬似的にNULLなんて
馬鹿なこともしないほうがよいということ。
>>日付でインデックス効くのか？的な議論をするなら、
>>日付にNOT NULL制約つけとけよ、って気ガス。
インデックスを効かすために、DB上NULL値を許さず（システム上は許す）、
さらに、2200/12/31 や 1800/01/01 を擬似的にNULLなんて
馬鹿なこともしないほうがよいということ。
825 ：仕様書無しさん：2007/05/06(日) 13:57:23
820 は YMDまでの項目に 平気でSYSDATEぶちこんどいて
日付=YYYY/MM/DD で条件指定して引っかからないとかいって、
１日くらい軽く悩む馬鹿なんだろうな ｗ
日付=YYYY/MM/DD で条件指定して引っかからないとかいって、
１日くらい軽く悩む馬鹿なんだろうな ｗ
そして、一日後やっと理解して、大威張り ｗ
漏れは日付は素直にDATE型使う人なんだが・・・。
あと、2200年や1800年なんてアフォな判定を思いつく方が
ステキなんだが。
判別するなら別フィールドや、別テーブルに分離する設計するけど。
それにRDBMSだと日付型にINSERTする時は型チェックはいるはずだから
＞YMDまでの項目に 平気でSYSDATEぶちこんどいて
なんて処理はそもそも発生しないはずでは？
即効で例外発生するのでは？
Oracleは通るのかも知れんが、DB2は通らんよ。
あと、2200年や1800年なんてアフォな判定を思いつく方が
ステキなんだが。
判別するなら別フィールドや、別テーブルに分離する設計するけど。
それにRDBMSだと日付型にINSERTする時は型チェックはいるはずだから
＞YMDまでの項目に 平気でSYSDATEぶちこんどいて
なんて処理はそもそも発生しないはずでは？
即効で例外発生するのでは？
Oracleは通るのかも知れんが、DB2は通らんよ。
>>820
問題をすりかえるのが下手だな、お前 ｗ
問題をすりかえるのが下手だな、お前 ｗ
831 ：仕様書無しさん：2007/05/07(月) 03:32:23
>>820
ガッ _, ,_ ガッ
ガッ_, ,_ （ ･д･） _, ,_ガッ
（ ･д･） Ｕ☆ミ （･д･ ）
⊂彡☆))Д´☆ミ⊃ ガッ
, ,∩彡☆ ☆ミ∩, ,
（ ） ガッ （ ）
ガッ ガッ
ガッ _, ,_ ガッ
ガッ_, ,_ （ ･д･） _, ,_ガッ
（ ･д･） Ｕ☆ミ （･д･ ）
⊂彡☆))Д´☆ミ⊃ ガッ
, ,∩彡☆ ☆ミ∩, ,
（ ） ガッ （ ）
ガッ ガッ
sqlは知らんがなにやら不毛で低レベルな論議をしているような空気は見切った。
833 ：仕様書無しさん：2007/05/07(月) 06:46:32
>>低レベルな論議
ぷ
ぷ
確かに下手な自作自演が見えるな。
日付を YYYYMMDD みたいな数字の連続で表したいなら日付表現のデフォルトの
設定をそうすればいいだけのことで、文字列型を使うのは効率が悪くなったり
バグの温床になるような気がする(文字ならなんでも入っちゃうから)。
設定をそうすればいいだけのことで、文字列型を使うのは効率が悪くなったり
バグの温床になるような気がする(文字ならなんでも入っちゃうから)。
20070368
20070229
そういや、日付項目で
YYYYMMDD
と
YYYYMM
の2種類が混在してるシステムがあったんだが
そん時は流石に文字列にしたなあ。
YYYYMMDD
と
YYYYMM
の2種類が混在してるシステムがあったんだが
そん時は流石に文字列にしたなあ。
200A0117
840 ：仕様書無しさん：2007/05/09(水) 02:31:13
いまどき、西暦使ってるなんてどこのバカだ。
宇宙暦だろうが！！
宇宙暦だろうが！！
府中。そこは最後のフロンティア。
2001円府中の旅
日付型はYYYYMMDDの方が良いと思うな
年から始まる日本には向いているんじゃない？
インターナショナルなシステムでは使えないだろうけど
年から始まる日本には向いているんじゃない？
インターナショナルなシステムでは使えないだろうけど
だから日付はDate型を使えと小一時間…(ry
845 ：仕様書無しさん：2007/05/09(水) 20:55:38
府中選管大和
03 DATE-WK PIC 9(08)
03 FILLER REDEFINES DATE-WK.
05 Y-WK PIC 9(04)
05 M-WK PIC 9(02)
05 D-WK PIC 9(02)
03 FILLER REDEFINES DATE-WK.
05 Y-WK PIC 9(04)
05 M-WK PIC 9(02)
05 D-WK PIC 9(02)
>>846
家でCOBOL見ても何か分からないｗ
家でCOBOL見ても何か分からないｗ
>>846でグーだと思うけどね、基本的に。
>>846なら、数年スパンの中間一致の月合計や後方一致もインデックス使用ですぐにだせる。
オラ屋やオラスレに言わせると、
ビットゥウィ～↑ン(歯磨き粉風に)や、不等号でくくるらしいが、
date型比較は秒単位まで考えなきゃならないし(まあデフォルトで00:00:00だけど)、
クライアント処理がアドホックに入力値から式をケースバイケースで作るのはかなりナンセンスだと思う。
こうなると集計するのはデータウェアハウスでなんて声も聞こえてきそうだが、
高いデータウェアハウスにはリスクもある。
基幹が更新性能が優れているのに対して、DWHは集計性能・計算性能に優れているが故に起こるギャップ、
それが、期末期首等のDWHに吸い込んだ後に起こる、遅延・修正。
遅延や修正が起こるたびにDWHに全データ吸い込み直しを行わなければならない事態もありうる(∵DWHは基本、更新が苦手)
脱線したけれど、まあ言いたいことは要は、基本というのは練られているものなので、その基本を疎か(≒COBOLERどうたら)はどうなんかねって感じか。
>>846なら、数年スパンの中間一致の月合計や後方一致もインデックス使用ですぐにだせる。
オラ屋やオラスレに言わせると、
ビットゥウィ～↑ン(歯磨き粉風に)や、不等号でくくるらしいが、
date型比較は秒単位まで考えなきゃならないし(まあデフォルトで00:00:00だけど)、
クライアント処理がアドホックに入力値から式をケースバイケースで作るのはかなりナンセンスだと思う。
こうなると集計するのはデータウェアハウスでなんて声も聞こえてきそうだが、
高いデータウェアハウスにはリスクもある。
基幹が更新性能が優れているのに対して、DWHは集計性能・計算性能に優れているが故に起こるギャップ、
それが、期末期首等のDWHに吸い込んだ後に起こる、遅延・修正。
遅延や修正が起こるたびにDWHに全データ吸い込み直しを行わなければならない事態もありうる(∵DWHは基本、更新が苦手)
脱線したけれど、まあ言いたいことは要は、基本というのは練られているものなので、その基本を疎か(≒COBOLERどうたら)はどうなんかねって感じか。
そんなOracle中心な事言われてもな。
DB2はんな事ねーし。
DB2はんな事ねーし。
もしやんなら
(DATE)>=to_date(x)
(DATE)<to_date(y+1)
とやったほうがいいんじゃないかな。
画面入力値はｷｬﾗが多いし、比較対照の右辺に検索ｶﾗﾑ持ってきてインデックス効かさず、全件検索するわけ？
(DATE)>=to_date(x)
(DATE)<to_date(y+1)
とやったほうがいいんじゃないかな。
画面入力値はｷｬﾗが多いし、比較対照の右辺に検索ｶﾗﾑ持ってきてインデックス効かさず、全件検索するわけ？
なんか昔のRDBMSが巻いた都市伝説ネタが豊富だな・・・。
DB2だと右辺だろうがINDEX効くんだが・・・。
DB2だと右辺だろうがINDEX効くんだが・・・。
853 ：仕様書無しさん：2007/05/09(水) 23:40:41
>>852
DB2のシェアって何％か知ってる？
DB2のシェアって何％か知ってる？
854 ：仕様書無しさん：2007/05/10(木) 00:38:56
俺の作ったシステムは西暦使わず皇紀を使う。
今年は皇紀2667年。
おかげさまで、2000年問題とは無縁だ。
今年は皇紀2667年。
おかげさまで、2000年問題とは無縁だ。
( ﾟ,_ゝﾟ)ﾊﾞｶｼﾞｬﾈｰﾉ
>>854
平安京に遷都まで読んだ。
平安京に遷都まで読んだ。
SybaseSQLServer Infomix Symfoware Teradata
>>853
AS/400,S/390から数えていいならDB2のホスト・基幹系でのシェアは
かなりのモノなんだが・・・。
藻前の脳内はおそらくパソコン程度のおもちゃで動くRDBMSしかイメージ
ないんだろうが。
AS/400,S/390から数えていいならDB2のホスト・基幹系でのシェアは
かなりのモノなんだが・・・。
藻前の脳内はおそらくパソコン程度のおもちゃで動くRDBMSしかイメージ
ないんだろうが。
つか、シェア云々言い出したらMySQLが最強のはずだが。
まあ、Oracle信者がシェアを言い出すと痛い結果に終わるから
そういう話はヤめとけ。
まあ、Oracle信者がシェアを言い出すと痛い結果に終わるから
そういう話はヤめとけ。
＞「左辺か右辺か」ではなく、「フィールドに対する演算結果との比較」をすると
＞全検索になるんだよ。インデックスの原理考えりゃ判りそうなもんなんだが。
演算の種類にもよるんだろうがExplain見ているとフィールドに対する演算しても
indexを使ってる。
今時のRDBは最適化が結構賢い。
たまにWebページで自慢毛にSQLのチューニングの話しているサイトとか
あるけど、そろそろそういう都市伝説は見直して欲しいと思うんだが。
いつのOracleだよ、って状態だな。
＞全検索になるんだよ。インデックスの原理考えりゃ判りそうなもんなんだが。
演算の種類にもよるんだろうがExplain見ているとフィールドに対する演算しても
indexを使ってる。
今時のRDBは最適化が結構賢い。
たまにWebページで自慢毛にSQLのチューニングの話しているサイトとか
あるけど、そろそろそういう都市伝説は見直して欲しいと思うんだが。
いつのOracleだよ、って状態だな。
はっはっは、33年後に同じシステムを使い続けてるわけないだろう？(笑)
>>865
1. とても素晴らしいコンピュータだったのでこっそり北朝鮮に密輸される。
2. 核ミサイル基地で使用される。
3. 金がないのでそのまま延々と使い続ける。
4. 33年後、誤作動して敵国に向けミサイル発射。もちろん敵国は日本。
1. とても素晴らしいコンピュータだったのでこっそり北朝鮮に密輸される。
2. 核ミサイル基地で使用される。
3. 金がないのでそのまま延々と使い続ける。
4. 33年後、誤作動して敵国に向けミサイル発射。もちろん敵国は日本。
>>862
もしかして、
x <= (DATE) < y+1
は、フィールドに演算使ってるから、インデックス使わないとか言っちゃってるわけか？
=,<,>は検索条件じゃなくて、インデックス効かない演算か？
ずいぶん標準からずれたSQLじゃねーか。
((DATE)=>x)<y+1とかネストじゃなくて演算とか言っちゃうわけか？
インデックス効かない主なのは、右辺(当然両辺含む)にインデックス列と、インデックス列に計算、インデックス列に関数だろ。
もしかして、
x <= (DATE) < y+1
は、フィールドに演算使ってるから、インデックス使わないとか言っちゃってるわけか？
=,<,>は検索条件じゃなくて、インデックス効かない演算か？
ずいぶん標準からずれたSQLじゃねーか。
((DATE)=>x)<y+1とかネストじゃなくて演算とか言っちゃうわけか？
インデックス効かない主なのは、右辺(当然両辺含む)にインデックス列と、インデックス列に計算、インデックス列に関数だろ。
868 ：仕様書無しさん：2007/05/10(木) 23:56:06
安田生命保険のシステムは、本当に皇紀を使っているらしい。
ウソみたいな話だが、どうやら本当らしい。
ウソみたいな話だが、どうやら本当らしい。
869 ：仕様書無しさん：2007/05/11(金) 00:47:28
>>868
なにか意味有るの？
なにか意味有るの？
>>867
>フィールドに演算使ってるから、インデックス使わないとか言っちゃってるわけか？
まさか。
>右辺(当然両辺含む)にインデックス列
イミフメ。
>インデックス列に計算、インデックス列に関数だろ。
このことを指して「フィールドに対する演算結果」と言ったつもりだったんだが
通じてなかったのなら済まんかった。
>フィールドに演算使ってるから、インデックス使わないとか言っちゃってるわけか？
まさか。
>右辺(当然両辺含む)にインデックス列
イミフメ。
>インデックス列に計算、インデックス列に関数だろ。
このことを指して「フィールドに対する演算結果」と言ったつもりだったんだが
通じてなかったのなら済まんかった。
873 ：仕様書無しさん：2007/05/13(日) 14:06:40
874 ：仕様書無しさん：2007/05/21(月) 00:08:40
age
875 ：仕様書無しさん：2007/05/22(火) 22:25:04
日付絡みはもう終わりか。
じゃ、こんなのどう？
主キー＝伝票番号、明細番号
伝票番号 明細番号 受注番号 金額 消費税
1000001 1 1001 100 0
1000001 2 1001 200 0
1000001 3 1001 300 0
1000001 4 1001 400 0
1000001 5 1001 500 75
1000001 6 1002 600 0
1000001 7 1002 700 0
1000001 8 1002 800 0
1000001 9 1002 900 0
1000001 10 1002 1000 200
コボラに言わせると
１．『伝票は５明細で一枚だから、主キーとは別に伝票番号を持って５行ごとに振っていく』
２．『消費税は伝票一枚の合計について計算するから、最後の行だけでよい』
らしい ｗ
どうですか？？？ ｗ
このバカっぷり ｗ
じゃ、こんなのどう？
主キー＝伝票番号、明細番号
伝票番号 明細番号 受注番号 金額 消費税
1000001 1 1001 100 0
1000001 2 1001 200 0
1000001 3 1001 300 0
1000001 4 1001 400 0
1000001 5 1001 500 75
1000001 6 1002 600 0
1000001 7 1002 700 0
1000001 8 1002 800 0
1000001 9 1002 900 0
1000001 10 1002 1000 200
コボラに言わせると
１．『伝票は５明細で一枚だから、主キーとは別に伝票番号を持って５行ごとに振っていく』
２．『消費税は伝票一枚の合計について計算するから、最後の行だけでよい』
らしい ｗ
どうですか？？？ ｗ
このバカっぷり ｗ
876 ：仕様書無しさん：2007/05/22(火) 22:25:51
主キーとは別に伝票番号 ×
主キーとは別に受注番号 ○
主キーとは別に受注番号 ○
877 ：仕様書無しさん：2007/05/22(火) 22:29:49
ま、コボルでやるんなら勝手にやってくれよ。
消費税フィールドを、別テーブル化するべきだよなっ。
880 ：仕様書無しさん：2007/05/23(水) 01:22:20
お前らは甘い！ 何もわかっちゃいない。
伝統ある由緒正しき正統なＣＯＢＯＬ流儀では、このように設計する。
伝票番号 受注番号 明細番号１ 金額１ 消費税１ 明細番号２ 金額２ 消費税２ ・・・・・
ここでのポイントは、
伝票１枚につき５明細なので、１から５まで横にフィールドを確保する。
伝票１枚につき１０明細まで対応できるように、ＦＩＬＬＥＲを６から１０まで確保しておく。
１から５までの番号は必ず全角で付けること。半角数字を使うヤツは死刑。
伝統ある由緒正しき正統なＣＯＢＯＬ流儀では、このように設計する。
伝票番号 受注番号 明細番号１ 金額１ 消費税１ 明細番号２ 金額２ 消費税２ ・・・・・
ここでのポイントは、
伝票１枚につき５明細なので、１から５まで横にフィールドを確保する。
伝票１枚につき１０明細まで対応できるように、ＦＩＬＬＥＲを６から１０まで確保しておく。
１から５までの番号は必ず全角で付けること。半角数字を使うヤツは死刑。
おみそれしやした
>>880
そうそうｗ orz...
そうそうｗ orz...
>880
おまいも甘い! 真のコボラーの恐怖はその先にもある。
とある製品の伝統的なコボラーな人の設計したRDBMSのテーブルの中身はこんなだった。
data varchar2(1000)
この一行だけ。そして、アプリ側で取り出したdataを切り出して使えと。
その実装に文句を言った少しだけSQLを知っているコボラーの提案。
「切り分けをアプリに勝手にやらせるな。selectの時にsubstrするように統一しろ」
……結局、出来上がった実装はでかいフィールド一つのテーブルがたくさんと、
テーブルの数に対応するだけのsubstrの嵐なviewのセットでしたとさ。
# ネタじゃないのが恐ろしい。
おまいも甘い! 真のコボラーの恐怖はその先にもある。
とある製品の伝統的なコボラーな人の設計したRDBMSのテーブルの中身はこんなだった。
data varchar2(1000)
この一行だけ。そして、アプリ側で取り出したdataを切り出して使えと。
その実装に文句を言った少しだけSQLを知っているコボラーの提案。
「切り分けをアプリに勝手にやらせるな。selectの時にsubstrするように統一しろ」
……結局、出来上がった実装はでかいフィールド一つのテーブルがたくさんと、
テーブルの数に対応するだけのsubstrの嵐なviewのセットでしたとさ。
# ネタじゃないのが恐ろしい。
884 ：仕様書無しさん：2007/05/23(水) 19:17:05
885 ：仕様書無しさん：2007/05/23(水) 19:22:29
受注ヘッダ
受注番号 消費税
1001 75
1002 200
受注明細
受注番号 明細番号 金額
1001 1 100
1001 2 200
1001 3 300
1001 4 400
1001 5 500
1002 1 600
1002 2 700
1002 3 800
1002 4 900
1002 5 1000
受注番号 消費税
1001 75
1002 200
受注明細
受注番号 明細番号 金額
1001 1 100
1001 2 200
1001 3 300
1001 4 400
1001 5 500
1002 1 600
1002 2 700
1002 3 800
1002 4 900
1002 5 1000
いくらコボラでも消費税は計算して出すんじゃないの？
テーブルに持たせて、なんかメリットあるの？
テーブルに持たせて、なんかメリットあるの？
>880
後で列を追加する為のダミーの約100カラムの空白項目が抜けてる。
後で列を追加する為のダミーの約100カラムの空白項目が抜けてる。
伝票の日付を参照する事が面倒と思うくせに、
横にカラムを並べるのは面倒に感じないのがCOBOLerの謎なところだな。
コード量としては後者の方が圧倒的にやってられない気分になれるはずだが。
横にカラムを並べるのは面倒に感じないのがCOBOLerの謎なところだな。
コード量としては後者の方が圧倒的にやってられない気分になれるはずだが。
891 ：仕様書無しさん：2007/05/23(水) 20:42:34
>>887って、キーで繋がっていればどこにあってもいいとか思ってるアホなんだろうな ｗ
コボラ以下 ｗ
コボラ以下 ｗ
>>887
まぁ、世紀化するのも大事だが、『入力した当時の状態』ってのが大事なんだよな。
消費税以外でもそういうことはあるぜ。
マスタへの外部キーだけじゃなくて、当時の名称もトランザクションに落とすってこともやることはあるんだよ。
いい勉強になったな ｗ
まぁ、世紀化するのも大事だが、『入力した当時の状態』ってのが大事なんだよな。
消費税以外でもそういうことはあるぜ。
マスタへの外部キーだけじゃなくて、当時の名称もトランザクションに落とすってこともやることはあるんだよ。
いい勉強になったな ｗ
テーブルを丸ごとメモリに展開するのが大好きなんだよな。
んで、それをなめながらちんたらちんたら処理。
すぐにロールバックセグメントが不足する。
んで、それをなめながらちんたらちんたら処理。
すぐにロールバックセグメントが不足する。
894 ：仕様書無しさん：2007/05/23(水) 20:50:35
>>890
お前バカだろ？ ｗ
>>889 様が言ってるのは
『入力された日付によって税率が異なるので計算が面倒』
ということ。
決して、>>880 がネタで言っている手法を支持しているわけではないんだな。
お前バカだろ？ ｗ
>>889 様が言ってるのは
『入力された日付によって税率が異なるので計算が面倒』
ということ。
決して、>>880 がネタで言っている手法を支持しているわけではないんだな。
>>890
論点をすりかえるときはもっとうまくやろうぜ！！ｗ
論点をすりかえるときはもっとうまくやろうぜ！！ｗ
896 ：886：2007/05/23(水) 20:55:59
いや、普通はその伝票を発行した時点の税率もしくは税込価格をレコードに埋めて終わりだろ。
マスタもたせるって・・・・。
マスタもたせるって・・・・。
898 ：仕様書無しさん：2007/05/23(水) 21:00:59
899 ：仕様書無しさん：2007/05/23(水) 21:03:17
900 ：仕様書無しさん：2007/05/23(水) 21:05:22
>>897
ついでにコテハンもな ｗ
ついでにコテハンもな ｗ
「正規化を崩すことを知らない887を叩くスレ」ですか？
おいら>>887しかレスしてないぜ。
つか、何が正規化を崩すことを・・だよｗばかかね君らはｗ
つか、何が正規化を崩すことを・・だよｗばかかね君らはｗ
903 ：仕様書無しさん：2007/05/23(水) 21:24:42
はああああ？
コテちゃうわ
コテちゃうわ
>>903
いや、使えって意味なんじゃないの？
いや、使えって意味なんじゃないの？
コボラはISAMとDBの違いがわかってないんだよな。。
FETCHすることしか頭にないんだから。
FETCHすることしか頭にないんだから。
906 ：仕様書無しさん：2007/05/23(水) 21:34:35
まぁ、入力当時の履歴を残しておくってことなんだろうな。
907 ：仕様書無しさん：2007/05/23(水) 21:37:51
>>902
えー、消費税をヘッダに持っているということで正規化が崩れていますが。
これは、税率をもたせるにしても同じこと。
やっぱ、>>891がいうとおりの亜フォですか？ ｗ
>>891もちょっと語弊がありますが。
えー、消費税をヘッダに持っているということで正規化が崩れていますが。
これは、税率をもたせるにしても同じこと。
やっぱ、>>891がいうとおりの亜フォですか？ ｗ
>>891もちょっと語弊がありますが。
伝票に発注元顧客マスタのIDだけ埋めておいたら、後で数年間の発注元住所別の
統計を出せるようにしてといわれて、住所が変わったお客様の分はわかりませんと
答えるしかなく大目玉食らった奴がいるぞ。
統計を出せるようにしてといわれて、住所が変わったお客様の分はわかりませんと
答えるしかなく大目玉食らった奴がいるぞ。
>>875の例ならどんな使い方するにしろ、素直に正規化したほうがパフォーマンスいいだろ。
正規化を崩すメリットは皆無。
正規化を崩すメリットは皆無。
910 ：仕様書無しさん：2007/05/23(水) 21:39:50
>>908
そうならないための正規化崩しなんだよな。
そうならないための正規化崩しなんだよな。
来年消費税が7%になるとしよう。
ほんで、施行日からマスタを7%に書き換える。
改正後、つまり来年以降に今年の伝票を参照する場合は、5%じゃないといけないわけだ。
ほんで、施行日からマスタを7%に書き換える。
改正後、つまり来年以降に今年の伝票を参照する場合は、5%じゃないといけないわけだ。
物品毎に税率変わったらどうするの～
ある期間からある期間の消費税率は一意に定まるだろ。
本気でわかってねーか。
本気でわかってねーか。
その税率が変わる日付を跨いで集計するクエリを書いてください
あほのJOIN～
921 ：仕様書無しさん：2007/05/23(水) 21:50:11
>>916
そのつどPG修正か....大変だな。
そのつどPG修正か....大変だな。
先輩！ロールバックセグメントが足りません！！！！！
>>914
まぁあんまし熱くなるなよ。
お前を怒らそうとしてるだけなんだと思うぜ。
お前がそうやって反応するから奴らも調子にのるんだよ。
だから、気にするなよ。
でも、お前の言ってることはおかしいけどな ｗ
まぁあんまし熱くなるなよ。
お前を怒らそうとしてるだけなんだと思うぜ。
お前がそうやって反応するから奴らも調子にのるんだよ。
だから、気にするなよ。
でも、お前の言ってることはおかしいけどな ｗ
FOR UPDATEをはずすんだ！
先輩！ロックと読取一貫性は関係ないのではないでしょうか
927 ：仕様書無しさん：2007/05/23(水) 21:54:52
>>920
苦しいな。
苦しいな。
アホだな。年間集計するクエリを書いて実行計画を見てみろ。
JOINでアホみたいにコストがかかるぞ
JOINでアホみたいにコストがかかるぞ
まあ別にいいやもうメンドクセエ
好きにやれよ
好きにやれよ
>>926
フロントで計算するのか？
フロントで計算するのか？
なんだか素人がMS-Accessで作ったような話だな。
なんでも連結連結
なんでも連結連結
>>926
で、お前の発言は、何番と何番と.....？
で、お前の発言は、何番と何番と.....？
>>926
フロントで計算するのか？
フロントで計算するのか？
>>931
そしたら寂しいくせによく言うよｗ
そしたら寂しいくせによく言うよｗ
936 ：仕様書無しさん：2007/05/23(水) 22:02:05
データウェアハウス的運用をまるっきり考えていないおばかさんが設計するとこうなります。
年次処理中はアクセスしないで下さい。ロールバックセグメントがパンクします。
だいたいさあ、DBに無理してつっこまなきゃいいじゃん。
まあ、COBOLで立派に動いてたシステムのリプレースなんてISAMで十分だろと
思うことは多々あるな。
思うことは多々あるな。
940 ：仕様書無しさん：2007/05/23(水) 22:09:03
941 ：仕様書無しさん：2007/05/23(水) 22:17:11
集計なんてPL/SQLでカーソル開いて一行一行フェッチしていけばいいだろ。
税率マスタは予めカーソル開いて連想配列に全件を展開しておくんだ。
これで高速になる。わかったかね。素人諸君。
税率マスタは予めカーソル開いて連想配列に全件を展開しておくんだ。
これで高速になる。わかったかね。素人諸君。
942 ：仕様書無しさん：2007/05/23(水) 22:19:48
PL/SQL
944 ：仕様書無しさん：2007/05/23(水) 22:22:18
Oracleに限定されちまったね。
ジャーナルデータをあーだこーだ弄って遊んでどうするよ？
ログみたいなモンだろ＞ジャーナル
キーとか正規化とか関係ねぃよ。
レジのはき出すレシート情報が書き出されていれば問題ねぃよ＞ジャーナル
逆に正規化されたり別計算ロジックぶっ込まれたり、冗談じゃねぇっつぅの！
ログみたいなモンだろ＞ジャーナル
キーとか正規化とか関係ねぃよ。
レジのはき出すレシート情報が書き出されていれば問題ねぃよ＞ジャーナル
逆に正規化されたり別計算ロジックぶっ込まれたり、冗談じゃねぇっつぅの！
946 ：69式フリーPG ◆hND3Lufios ：2007/05/23(水) 22:24:08
とりあえず、おまいさんらがDBを愛してやまないことだけはわかった。
伝票 == ジャーナルデータ == 後で更新されない
これを前提にして索引構成表（Oracle)やクラスタ化インデックス（MS-SQL/MySQL)に
しておくと、週報や月報用の集計が高速になります。挿入順に並べられるからな。
これ、豆知識な。
これを前提にして索引構成表（Oracle)やクラスタ化インデックス（MS-SQL/MySQL)に
しておくと、週報や月報用の集計が高速になります。挿入順に並べられるからな。
これ、豆知識な。
ジャーナルの行き着く先はDWH(データマイニング)なんだよ。
使い道が違うんだ。
現場ではマスターとかと同列に語れないんだよ。
使い道が違うんだ。
現場ではマスターとかと同列に語れないんだよ。
そろそろ次スレたのむ
950 ：仕様書無しさん：2007/05/23(水) 22:38:07
やめとけ！！
951 ：仕様書無しさん：2007/05/23(水) 22:40:36
更新系、参照系は要求が全然違うからね。
同じデータでも、更新される可能性のあるうちに存在するテーブルと、
更新の終了したテーブルは分けたりするんだよ。
同じデータでも、更新される可能性のあるうちに存在するテーブルと、
更新の終了したテーブルは分けたりするんだよ。
953 ：仕様書無しさん：2007/05/23(水) 22:43:46
コボラは横長ＤＢがお好き ２カラム目
http://pc11.2ch.net/test/read.cgi/prog/1179927770/
http://pc11.2ch.net/test/read.cgi/prog/1179927770/
954 ：仕様書無しさん：2007/05/23(水) 22:45:52
>>953
ガッ _, ,_ ガッ
ガッ_, ,_ （ ･д･） _, ,_ガッ
（ ･д･） Ｕ☆ミ （･д･ ）
⊂彡☆))Д´☆ミ⊃ ガッ
, ,∩彡☆ ☆ミ∩, ,
（ ） ガッ （ ）
ガッ ガッ
ガッ _, ,_ ガッ
ガッ_, ,_ （ ･д･） _, ,_ガッ
（ ･д･） Ｕ☆ミ （･д･ ）
⊂彡☆))Д´☆ミ⊃ ガッ
, ,∩彡☆ ☆ミ∩, ,
（ ） ガッ （ ）
ガッ ガッ
955 ：仕様書無しさん：2007/05/23(水) 22:46:59
POSレジやれ。勉強になる。
それが全てではないし、最強でもないが。
そんだけだ。
それが全てではないし、最強でもないが。
そんだけだ。
DWHを念頭において全テーブル
create table hoge (
col char(10000)
)
とします
create table hoge (
col char(10000)
)
とします
列のバインドが楽でいいね。
金融機関の勘定系処理で毎日為替レートが変わるシステムとか
組んでみれば、正規化は多少崩したほうが楽ではある。
が、消費税とか保険の利率程度の変更だとJOINした方が
パフォーマンスいいだろうなぁ。
組んでみれば、正規化は多少崩したほうが楽ではある。
が、消費税とか保険の利率程度の変更だとJOINした方が
パフォーマンスいいだろうなぁ。
>>958
普通為替レートと消費税を同じ次元で扱うか？
普通為替レートと消費税を同じ次元で扱うか？
>940
> 一度やってみたかったのに、ガチでやったやついるのかｗｗ
例えば某社のレセコ(ry
消費税とかは後から計算できるかどうかより、実際に請求した金額の履歴としての
意味から残しておくようにするけどな。俺なら。
履歴系データってそういうもんだろ。
> 一度やってみたかったのに、ガチでやったやついるのかｗｗ
例えば某社のレセコ(ry
消費税とかは後から計算できるかどうかより、実際に請求した金額の履歴としての
意味から残しておくようにするけどな。俺なら。
履歴系データってそういうもんだろ。
つか、それ正規化してもレコードのコンパクト化には殆ど寄与しないよな。
正規化はコンパクト化とはイコールじゃないだろ。
結果的に一部コンパクトになる事が有るにしてもだ。
結果的に一部コンパクトになる事が有るにしてもだ。
毎度JOINするなら冗長化させた方が速い場合も
消費税は、相手がAなら端数切り上げ、Bなら端数切捨て、
一回の注文でも請求書がN枚になったらN回に分けて計算、とか
色々言われたことあるな。
一回の注文でも請求書がN枚になったらN回に分けて計算、とか
色々言われたことあるな。
消費税はそれを決めるルールに基づいて（場合によってはマスタ参照もありうる）、
その値をそのまま伝票を切るときに伝票に書き込んで終わり。
連結しても意味が全然無い。パフォーマンスもあがらない。
その値をそのまま伝票を切るときに伝票に書き込んで終わり。
連結しても意味が全然無い。パフォーマンスもあがらない。
てか問題なのは消費税カラムの必要性とかでは無いだろ…。
脱線しすぎ。
脱線しすぎ。
967 ：仕様書無しさん：2007/05/24(木) 01:49:57
もとはといえば>>887のａｆｏが....
消費税は、端数のルールが途中で変わる可能性がある。
履歴と言う意味からも実際の請求額を残しておく。
このときに、表示用に税率を残しておく場合もありえる。
履歴と言う意味からも実際の請求額を残しておく。
このときに、表示用に税率を残しておく場合もありえる。