この会社辞めようと思ったシステム設計

この会社辞めようと思ったシステム設計。
プログラマとして幻滅するシステム設計。
プログラマを悩ませるシステム設計。
をつらつらと綴っていって頂戴。

■関連スレ

この会社辞めようと思ったソースコード＃２
http://pc.2ch.net/test/read.cgi/prog/1001076034/

この会社辞めようと思った上司の一言＃２
http://pc.2ch.net/test/read.cgi/prog/1003497181/

2

何でこの板ってこういうスレばっかたつんだ・・・（鬱

パスワードが生のままＤＢに格納されている。

（´−`）.｡oO（みんなつらいんだなぁ）

非正規化をしらない先輩がＤＢ設計はテーブルがたくさんある。
列（属性）が２つだけのテーブルが無数。

こんなにごちゃごちゃした画面本当にＶＢで組ませんの？
いろいろ言ったけど結局ＶＣは使わせてもらえず。
まっ、骨格だけは作るけど後は引き継ぎの人よろしくね。

認証システムがばらばら。
新しいシステムを作るごとに専用のユーザＩＤを作る。
・勤怠システム
・旅費システム
・総務システム
・社員ポータル
・グループウェア
・ＢＢＳ
全部ユーザＩＤが違う。

>>8
グループウェアにログインしたらそこから全部のシステムに行けるように
すればそれで万事終了じゃん。

組織情報（３００件）とユーザ情報（８万件）を一つのテーブルで扱っています。
主キー（上の人はと言っているが違うー）が
レコードごとに変わるのは勘弁してくれ！

いままで一所懸命勉強してきたのは何だったんだと思わせられたよ。

一意制約皆無。
ほぅ、全部PGでチェックしろと...?

バグの許容範囲は全システムの１％っていうのがあるんだけど・・・
間違っているよね。

１０です。
>>11
もちろんＰＧでチェック！
ユーザＩＤがＺＺＺＺ（ＮＵＬＬって概念ないみたい）だったら
組織ＩＤを見る。
組織ＩＤがＺＺＺＺ以外だったら
・
・
・

１０です。
>>11
で設計者が必ず聞くことは「何ステップかかった？」
ステップ数が大きいと設計しがいがあるらしい。

>>13
その上司ってCOBOLERか？
確かに強烈にあふぉなテーブルだな。

>>12
> バグの許容範囲は全システムの１％っていうのがあるんだけど・・・
> 間違っているよね。
どっちに間違っている？多すぎる／少なすぎる。
無しは現実的ではないだろう。

ところで１％ってどんな単位なんだろう。
○件／1000STEPとか○件／１人月とかならわかるけど。

ところでＶＢとかＶＣとかで開発してらっしゃる方、システムの規模は
どのように表現しています？
昔Accessでの開発をやらされたときにコボラ部長に「おい何ステップ
程度の規模なんだ？」といわれて困ったことがある。

１０です。
>>15
「俺にはＣＯＢＯＬは無理。ＤＢ設計に退くよ」と言ってＤＢ設計やってるみたい。
まじ強烈だぜ。そのテーブル。
さらに値が強烈にコード化されてたり。
１〜３桁目は○○で、４桁目がＺがあったら・・・

ちゃんと設計書書いているならまだいいじゃん。
俺んところなんて上から要求仕様もらって「作れ」だもんな。
SEの仕事っていったい・・・。
引継ぎ時も関数設計書っつーものもらって引継ぎ完。
データフローとか用意してよ。アクセス使っているんだしさ。
今日は辞めると言ってしまった。ちょい鬱・・・。

どーいうわけかデータベースの値がCSV文字列で
1文字目が$だったら○○の意味。
中間に@があったら△△の意味。
@以降に#があったら□□の意味。
2つ目のデータは○○の値が●●の意味。
以下略。
もうねアホかと・・・。

>>20
うちにもあった。
ＤＢの値がＣＳＶレコードをそのまま入れてるやつ。
その値を取得してからプログラムでＣＳＶを分析するコード書いた。
あほな仕事だった。

>>21 だけど >>21の文章が変なので直します。

＞ＤＢの値がＣＳＶレコードをそのまま入れてるやつ。
ＤＢのある列がＣＳＶレコードになっている。

間違いなく誤用。

1)
DBのテーブル上にフラグ変数。動作中に触られたら死ぬので
起動時のみ読み込むことにしたが、知らん奴が触ると死ぬ。
※カプセル化ってなーに？オセーテ。

2)
DBのテーブルを使った通信。レコードの先頭に時刻をつけ、
最終アクセス時刻より新しいのが新着だが、
時計がずれたらちゃんと通信できなくなる。
※これだからDBしか知らん奴は。

3)
>>20に近いアイデア。
以前、外注から、
「DBを変更すると、プログラムの変更費用が掛かる」と
以前言われたことが悲しかったらしく、
「DBの変更無しにデータ構造を変更する」
という画期的アイデアをひねりだしたということらしい。
※わりとポピュラーなのかも。

やっぱり変なＤＢ設計に関わる問題ですが
ユーザＩＤがあるきっかけで変わります。
ユーザＩＤの列はこんな感じ。

・１〜２文字目は入社年
・３〜４文字目は部署
・５文字目は社外Ｗｅｂアクセス許可フラグ
・６文字目は社外Ｅメール使用許可フラグ
・７〜１０文字目は通し番号

>>24
その会社じゃあ同一年入社・同一部署な奴が数千人単位でいるのか？
でかい会社だのう。

>>25
中小のシャチョ−が「いつかは・・・」なんて妄想しただけかも

>>24
ｶｺ良過ぎです。惚れました。マヂで。。。
でも、そのカラムに社員名と生年月日があればもっともっとｶｺｲｲYO！

>>24
それはきっと、DBサーバの負荷を減らすための工夫なんだYO!

>>26

> ｶｺ良過ぎです。惚れました。マヂで。。。
> でも、そのカラムに社員名と生年月日があればもっともっとｶｺｲｲYO！

　むしろ、年齢かと・・・

>>28
で、その年齢は入社年から加算されることがないという罠つきですね。

>> 26
2月29日問題が起こりそうですね。

>>29

部署と同程度には変更してもらえますよ、多分。

（っていうか蛇足？）

>>28
もと−もと−ｶｺｲｲね！
ついでに欠勤日数も入れちぇ！（ｗ

age

ＲＤＢのテーブルをＣＳＶで出力。
それをＦＴＰでＧＥＴ。
そのＣＳＶをＣで整形してＨＴＭＬ出力。

メインとなる部分はＤＢプログラミングだけど
サブとなる部分はＣＳＶとしてＧＥＴしてテキスト処理。

CSV使うのやめようよ。
XMLでいいじゃないか。

>24
移動のたびにＩＤを覚えなおさないといけない
ユーザーが大変だね。
それともそもそも社員の定着率が低いからそんな必要ないとか？

ユーザーから業務の年間処理件数やもろもろがぜんぜん出てこなくて、ＤＢの
論理設計が遅れに遅れた．．．
それを聞いた上司が工程表を見ながらひとこと。
「なんだＤＢは遅れてるな。もう物理設計の時期なんだよ。論理設計飛ばして（！）、
物理設計入ってよ。」
俺にどうしろと．．．

論理設計を飛ばせば？

DBテーブルに汎用フラグカラムがある．それもたくさん．
ある条件にヒットするレコードはフラグ１を立てて，（ここでUPDATE）
そのフラグ１のレコードのみを対象に別のテーブルと付き合せて
ヒットしたものにフラグ２を立ててうんたらかんたら．
俗に言うファイル転がし．．．

ホストの匂いがぷんぷんした．RDBなんだからさぁ．．．．

>>37
安心しろ。そのうち全部飛んでなくなるから。

>>39
ファイル転がしっていうんだ。勉強になった。

取引先のマスタがあるのはいいんだけど、
取引先の下にぶら下がる２次店のデータが１取引先１テーブル

取引先マスタ： コード、名称、テーブル名

２次店のデータを取る為には、取引先コードの先頭N文字が１次店のコードだから、
それを元に取引先マスタ引いて、テーブル名取り出して、動的SQLを組み立てて。。。

で、他のマスタにも「テーブル名」って名前のカラムを大量に発見して、、、
逃げました。

人事マスタの性別が
0:男
1:女
9:その他
だった。

ｿﾉﾀ!?

>>37
コーディング工程を飛ばす方が納品が早くなると説得しなさい

>42
男でも女でもない人は実際居るよ。

WWW から取得可能な銀行のデータ取りに行くだけなのに、
わざわざ、電話かけてデータを取得する Visual C++ で
作られたツールをタイマーで動かし、送金処理を行われた
かどうかを pcAnywhere を動かし Explorer でファイル
の中身を目視で確認というムダを毎日繰り返すことに何の
疑問も感じず日々を過ごす無能がいる会社。

>>44
や。人事マスタなんだから、戸籍上の性別を登録するだろ。

>42
わ、分からない場合とか‥‥？

ｹﾂｴｷｶﾞﾀｼﾞｬﾈｪｿﾞ

>>42
今担当している市役所関係の性別マスタも、ほぼ同じです。

　０：女
　１：男
　９：不明

ですが。

>>48
すげぇ。
やっぱそういう拡張性が設計には必要なのか

ﾃﾞﾓ ﾌﾒｲｯﾃﾅﾝﾀﾞﾖ!ヽ(`Д´)ﾉ

抱きしめて 男を女をﾌﾒｲをー
生きてるだけーじゃさーみーしいーよー♪

>>42
昔、ある証券会社の新規口座開設の申込書で、

性別：男・女・その他

ってのがあった。

その時、応対していたのはキレイなネーチャンだったけど、
もしかして「その他」なのか、っていっしゅん疑っちまったよ。

性別不明の焼死体用か？（´д｀；）

釜、鍋用です。。。

>>49
他にも、住民の区分マスタには
　・住民
　・異動
　・行方不明
　・失踪
　・失踪確定
　・死亡（通常）
　・死亡（殺害）
など、妙に怖い項目もあります（ｗ

ふたなり(;´Д`)ﾊｧﾊｧ

CREATE TABLE 社員テーブル
(
　DAT1 VARCHAR(100),
　DAT2 VARCHAR(100),
　・
　・
　・
　DAT100 VARCHAR(100)
)

>>56
FIELD名に連番が振られていると、マクロでざぁ〜っと
展開できてラクだ。

ｿｳ ｵﾓｳｺﾄﾆ ｼﾖｳﾖ･･･

>56-57
そいで、フィールド名（連番）とフィールド名（データの名前）の対応テーブルとかが
あったりするんだ、きっと（ｗ

VBAに亜土民のパスが生め込まれていた

APPS が似たような感じだけどね

法人の性別はどうなるのだろう。

固定長のファイルレイアウトをそのまま Access でテーブルに。
全てのフィールドが文字列型で、隙間にはスペース。

国の研究機関はナゼこんなものを．．．

性別を "男","女" と文字で持たせるのはどう？
データ表示時にわかりやすいし、性別マスタも要らないし
コード化しても1バイトしか違わない。

enum{aaa,aab,aac,aad,aae,aaf,aag,aah,aai,aaj,
………………………………………………………………
………………………………………………………………
………………………………………………………………
………………………………………………………………
………………………………………………………………
………………………………………………………………
rkl,rkm,rkn};//フー

>>56
sed&正規表現使えば連番なんて使う必要なくなる

>>63
性別コードと性別名が一緒のテーブルに存在していることも珍しくありませんでしたが、何か？

sex char,
check( (sex='M') or (sex='F') )

ってのはアリ？

>>66
性別マスタ以外だよな？
まあ、性転換するような奇特なやつが出ない限り
大丈夫そうだからまだマシか。

複雑な問い合わせする必要がなければ、RDBMS使うのやめようよ。

金は掛かるし、手間は掛かるし、ベンダごとにちょっとづつ仕様が
ちがうのに、営業は簡単に移行の話もってくるし。

メモリマップドファイルとかローデバイス直とかで普通にやるほう
が楽だし融通利くし、金も掛からんし。
今ムリヤリDB使ってるシステムの大半は、これですんじゃうもの
バッカリだと思うよ。単にログとるのに、あるいはテンポラリバッファ
の変わりにDB使うなどという奴までいるからな。

物を知らないやつは、とても常識では考えられない事を平気でやるもん
だよ。

ERDだのUMLクラス図だの設計図を書くとき、全部を一枚の図の上に
ぐちゃぐちゃ書こうとするヤツラが会社行くとよくいるが、

オマエラ、そんなもん見せられてすんなり理解できる奴がいると思う
のか？説明の道具のはずなのに、それを作って自己満足することが
目的になってねえか？本末転倒バカばっかりで困るよ、ほんとに。

>>62
それはね、その研究機関の入り口をくぐると、パンチカードとフォートランの
時代に否応なくタイムスリップしてしまうからだよ。

いや、性別マスタには”男性”　”女性”　”不明”
個人情報の性別名項目には　”男”　”女”　”　”　（ブランク）

>>54 =66,72

・行方不明
・失踪

これって、どう違うんでそ？

潜水艦にアテ逃げされた船の乗組員で遺体が上がらなかった時とかが、前者なんでしょうか？

「捜索願い」が出されると、「失踪」フラグがセットされるんでしょうか？　身寄りが
ない場合、あらかじめ本人が「失踪届」を出してから、失踪するのが、正しい失踪の仕方
なんでしょうか？

それと、「拉致」とか、オウム信者向けなどに「転入届け不受理」なんてのもあるんで
しょうか？　出しわすれたりすっと、役所の人間が失踪した人を探し出して、「失踪扱い
にしますけどいいですか？」って確認するんでしょうか？（T_T)

「性別コードと性別名が一緒のテーブルに存在」だけど、どっちかが戸籍上の性別で、
あとの方は窓口の担当者が主観で決めて入力してるなんてことはないですかね？

金属探知機で「玉」の有無を判定してるとかね。　但し女の人でも、調教中で飛びっ子
入れたままだと、センサーが誤動作して ...。

あと、コンビニのレジみたく、勝手に人物評価されてランク分けするテーブルとかあったり
しますか？　ﾋﾞｸﾋﾞｸ

>>70

まさに同意。

UML図 っていうのは、保存してとっておくものじゃなくて、開発者同士、
意思疎通のために、ちょっと使うくらいのものなんだよね。
UML図は紙に書き、使い終わったら破り捨てるものだ、という、この
根本的なルールが決められてないのが UML 最大の難点だとマジで思う。

とっておいても、どうせ設計は変わっていくものなんだから、意味はなし。

>>73
役所の考えなんてわからん（稿
漏れは単にデータ移行作業しただけなんで。
とはいえ、意味を知らないままってのは嫌だったんで、一応それについても聞いてはみたけどな（当時）

失踪、は夜逃げとかに使われるみたい
行方不明、は突然消え去った人、理由とかが一切不明な人らしい
行方不明→死亡という展開はあるらしい、

ぐらいしかわからんかった

ＣＲＥＡＴＥ　ＴＡＢＬＥ　ＵＳＥＲ＿ＴＢＬ
（
　ＣＳＶ　ＶＡＲＣＨＡＲ（１００００）
）

ＣＳＶ形式のレコードがまんま一つのフィールドに格納してある。
こうなると単なる高価な入れ物にすぎない。
実質プログラムの中心はテキスト処理が大半を占める。

行方不明になってから７年たつと、利害関係人が裁判所に請求して、
失踪宣告ができます。失踪になると、その人の財産がもうその人の
物ではなくなります。死亡に近いかも。民法第３０条です。お調べあれ。

俺がシステム設計してる。

RDBMS使うのいいけれど、正しい使い方をまともに勉強して欲しいね。
リアルタイムの制御プログラムだのプロトコル変換プロクシだの、
その手の仕事で使えと迫られる。
オラクルの池田だのあの辺の営業トークを引用して
「データベースの必要性」と演説をぶたれる。

＞プロトコル変換プロクシ

これにどーやってRDBM使えというんだろう？
冗談が好きな上司ですか？

>>80
冗談だと思うよね？フツーなら。
警報を表示するクライアントPCとの通信をDBでやる。
テーブルに文字列をインサートするのを
クライアントPCが30秒に一回SELECT文でチェックしてる
驚愕のクライアント･サーバーシステム。

81だがちょっと補足します。
常識的にはソケットとかセマフォとか環境変数とかそういった
イッサイガッサイの全てをDB一つで済ませようという思想なんです。
（唖然）。

システム設計、ではなくシステム設計者が

　プロコトル（何度指摘しても言い間違える）
　デーバッグ（必ず最初を延ばす）
　コンピラー（何度指摘しても言い間違える）
　シュミレーター（よくある）
　ビジュアルスツディオ（Stdioと思ってたらしい）
　フロントアンドユーザー

と発音、仕様書にまで書いてたときは辞めたくなった。
　

>>83
そんな奴でも仕事ができる業界だったか？

その人、それまで設計チームのサブ担当だったようで・・・その時が初めてのメインのようでした

コンピラー、はたまに言い間違えてコンパイラーになってた。

>>86のレス読むまで何の言い間違えかわからんかった

>>87
金毘羅かとおもった

最近、一般の人材派遣会社が増えてきたので、フリーでも
３０万以上の仕事は少ないぞ。
コネで４０万以上の仕事あるなら、即効決めた方がいい。

↑誤爆？

　…お願いですから、""(ヌル)と" "(スペース)をTrueとFalseの意味で
使うのは止めて下さいです…

http://herz.pobox.ne.jp/kamui/shisso/info.html
だから、行方不明->失踪(みなし死亡)と、
行方不明->死亡、の両方の展開があるのでは？