複雑怪奇なSQL文に笑えてくる
前回は、GridViewが大変だと騒ぎましたが、ここの文化がわからない。
仕様書なんてレベルのものはあるわけもなく、デグレスパイラルが止まらないから設計書を起こして欲しいって。。。
検索のSQLだけど、意味がわからないことが多々ある。
なぜわざわざUNIONしたがる？
帳票形式になるならまだしも、なぜ単票形式なのに、しかも１件しかヒットしないのに、UNIONするんだろう？
メインテーブルになければ別のテーブルで補助情報だけ持ってきたいだけですよね？
だったら、登録時にやってる処理を検索時にもしたらすっきりしない？
わざわざ補助情報のテーブルにない項目をNullで作ってUNIONでつなげる意味わからないですけど。
しかもその情報をさらにテーブル名つけて計算式だけの項目を作って、またそれもテーブル名つけてまた大きな括りのそれ、SQL中でしなくても良くない？ってことをしている。
だから
別名をどのテーブルから持ってきてるのかをまず小さい単位から見なきゃで、それがメインテーブルなのか補助テーブルなのか。
UNIONのメインと補助で横に並べたらフィールドの並びが逆のところがあるし・・・。
なんでうまくいってるんだ？
ま、どっちかしか値がない作りだからだろうけどね。
だって補助テーブルはメインテーブルのキーをExsitまでしてつなげてるんだから。
アホでしょ。
うーん、思考回路が複雑にしすぎてわからなくなるパターンだね。
だから
デグレスパイラルになるんだよ。
なるわな。
何がどこから持ってきてるのかほんとわかんないんだもん。
しかもいらないフィールドまで作ってるし。
画面自体は単純なのに、なんでそんなことになるのか知りたいわって思ってたけど、なるかもねと思う。
で、設計書と簡単に言うけど、それはどのレベルなんですか？と確認したら詳細設計よりの基本設計書って。。。
サンプルもらってその通りにしたら足りないって。
え？あっちの画面の方が複雑であれでOKだったのにこれで足りないの？
しまいには
「設計書書いたことありますか？」って・・・。
オタク様のはないわな。
ゼロベースで寄越してもらえば、プログラム設計書を起こしますよ。
でもね
基本設計書は無理よ。だってどういう思考で作り始めたかなんて全然読めないもん。
まず画面があるから画面項目一覧を作るじゃない？
そこからバインドするフィールド名を書いてって感じだったけど、結局、新規の場合と修正の場合で見ているテーブルが違うんだからわけないと表示条件が複雑になるって言うので結局、メンテナンスが楽にって言われても両方書きましたよ。
だって足りなきゃ「書いたことあります？」ってかなり失礼なことを言い出されるわけで。
保存はまぁそれぞれのテーブルに更新かけてるだけだから、抜き出せばいいはずなんだけど。
どこで何がデグレスパイラルになってるかわかんないから、バグがないものを作り直したいと言われても意味がわかんないわ。
歴史のある会社のシステムは怖いよぉ〜。
もうね、半ば見ちゃいけないで進んでしまっている部分が多すぎる。
それをいちいち対応している予算も時間もなかったんだろうけど。
仕様書作った範囲では何がどうデグレってるのかはわからなかったんだけどね。
ドロップダウン入れたら、何かが動くとかあるわけでもなく、条件付きで登録があるわけでもなく。
その単票に来る前の検索画面がもっとひどかったけど。
これからあれも紐解くとなると死ぬかも。
心の声がダダ漏れそう・・・
「バッカじゃないの。」って。。。
検索画面で検索条件でGridViewに表示しているんだけど、そのSQL文は実は単票と抽出条件が違うだけで同じわけ。（検索画面なのに修正する機能があるって不思議な作りだから。これがデグレの原因か？）
でも、書き方が違ってて先週も悩んでた
ばかり。
アホじゃないのか？
しかもLeft Join が多発中だし。他は(+) = なのに。
はぁ〜。プログラミングしてる方がよっぽど精神衛生上はいいんじゃないかと思われる。
はぁ〜なんで〜？？？
ってつい言ってる自分がいるもんね。
コメントが少なすぎるけど、修正履歴が残りすぎてるから見づらくてデグレの温床となっているということにもなってる。
たまにはちゃんと登録グループなりの記事にしてみた。
そう、私の登録グループは「プログラミング」らしい。
最近、時事ネタに偏ってるけど、本当はね、仕事の愚痴を書くつもりでもなかったんだけど。
