[その他]
HOW TO ABC..
投稿者からのアピールポイント
実際にあった某システムの超重要なマスターのテーブルSQL。 カラム名はまんまこの通り。
create table item_master ( A varchar(2000), B varchar(2000), C varchar(2000), D varchar(2000), E varchar(2000), F varchar(2000), G varchar(2000), H varchar(2000), I varchar(2000), J varchar(2000), K varchar(2000), L varchar(2000), M varchar(2000), N varchar(2000), O varchar(2000), P varchar(2000), Q varchar(2000), R varchar(2000), S varchar(2000), T varchar(2000), U varchar(2000), V varchar(2000), W varchar(2000), X varchar(2000), Y varchar(2000), Z varchar(2000), )
使い方ヒント: 「これは臭う」という行を見付けたら、各行の
をクリックしてマーキングしておきましょう(要Twitter OAuth認証)
コメント(12)
ちょっと心配になったんですが、
> 某システムの超重要なマスターのテーブルSQL。 カラム名はまんまこの通り。
とあるんですが、貴方が守秘義務違反に問われる恐れはないんですかね。
万一、セキュリティ要件の非常に高いシステムで、難読性確保のため意図的にやってたんだとしたら。。
１つは全カラム暗号化のためにvercharで長さも冗長に取ってあるという説。 検索性も無いしキーも使えそうにないのでデータベースとしては恐ろしく使いにくそう。 １つはカラムが固定長文字列しか使えない時代から悪い継承をしたか。 今でも何でもvercherな設計する人は居るから、そういうのは潰したい。
このまま"AA", "AB"ってすると "AS" あたりでエラーになりそうですねぇ。。。
難読性の確保のために意図的にやってたとしてもこれは開発の段階で確実にバグのもとになる。あと何より香ばしいのは、このテーブル、主キーがないw
> 難読性の確保のために意図的にやってたとしてもこれは開発の段階で確実にバグのもとになる。
> あと何より香ばしいのは、このテーブル、主キーがないw
それが難読性向上のための手段なんだもの。突っ込んでも仕方がない。
。。っと、想像の域を出ない話を勝手に膨らますのは、このくらいにしておこうっと。。
これが難読化設計か!!
これが難読化設計か!!
ききかじりでしかないけどメモリが少なかった時代の遺産じゃないのかな。テーブル構造を複数読み込みたくないので全然違うタイプのレコードをぶちこんでたという。 「A=通しID B=type C=個別ID」までが共通で、「B=顧客 なら C=顧客ID D=名前 E=TEL ...」、「B=商品 なら C=商品ID D=商品名 E=価格 ...」みたいに読み替えられて行く。だからフィールド名はつけられないし、型も定義できず無難なVARCHARに。
コメント投稿には、twitter認証が必要です。
Twitter認証
DB 設計の段階で潰せ