今まで見た中で最もひどいDBのテーブル設計は? 35
ストーリー by hylom
女将を呼べ 部門より
女将を呼べ 部門より
あるAnonymous Coward 曰く、
今まで見たもっともクソなテーブル設計というブログ記事が話題になっている。
ここで言及されている「クソなテーブル」は、ありとあらゆるデータが1つのテーブルに放り込まれており、また各行にどのようなデータが納められているかを区別するための列が設けられているというものだったそうだ。
見方を変えれば最近普及が進んでいるKey-Valueストア型データベースのようにも見えるが、通常のSQLデータベースでこのような使い方をするのは確かにひどい。
ちなみにこのような設計は、SQLアンチパターンにて「Entity-Attribute-Value」として紹介されている。
1テーブルに全部格納するのは時として必要 (スコア:3, 興味深い)
後半部は兎も角、前半部(=1つのテーブルで済ます)は、通常のSQLデータベースでもそういう使い方することあるよ
殆どのフィールドを検索条件に用いることがあって、しかもテーブル全部見ないといけない検索をする時はそれが一番速いから
設計としては美しくないかもしれないけど、実用上はそのほうがいい、ってことはある
自分が見た中で一番酷かったのは、おそらくシステムの拡張への対応を手抜きするためだったんだろうけど、たとえば「電話番号」のフィールドに「携帯電話」を付け足して、「000-000-0000|000-0000-0000」みたいに「|で区切って格納すること」とかいう変な要件加えてる、みたいなDBかな。至るところにそういうフィールドが混在してるの
関係ないけどDBのテスト用IDが「scott」ではなく「tiger」とだけ書かれていたので
パスワードが「scott」なのかな、と思ったらログインできず、発行者に問い合わせたら「bunny」だったことはある
「パスワード書かなくても類推できると思った」じゃねえよ馬鹿
Re:1テーブルに全部格納するのは時として必要 (スコア:1)
「パスワード書かなくても類推できると思った」じゃねえよ馬鹿
腐った女子種目のタイ&バニの情報共有強要するのはセクハラだと訴えるべきところですね。
Re: (スコア:0)
POSレジの伝票テーブルで1レコードに128カラムも項目があって、行番0がヘッダレコードになっていて、明細項目が行番1以降にずらずら並んでいる。1伝票処理するのに馬鹿でかいレコードを複数処理しなければならない上に、ストアドプロシージャで簡単には処理できないデータ形式だったんで、大した処理ではないのにステップ数ばかりが増える。その上開発言語がVB2だったから地獄だった。
Re: (スコア:0)
そもそも、外部のデータフォーマットそのままだったりするしね。
見易く整理するのも良いけど、ジャーナル的に使われていたりする生に近いデータだと、フォーマットを弄る方が後々祟ったりするし。
元記事はエクセルに立ち向かうデータベース第一部完みたいな感じだが (スコア:1)
-- 哀れな日本人専用(sorry Japanese only) --
著者名(1)←丸1 (スコア:1)
"開始〜終了" みたいに (スコア:0)
昨今のUnicode前提の環境では問題の出る文字 (波ダッシュ・全角チルダ問題 [wikipedia.org]) が列名に含まれていてテスターが悲鳴を上げてたりしたこともありました・・
予備項目 (スコア:1)
今後、項目が増えたときのために、
"予備1", "予備2" ...
という列が定義されている。
実際、その項目が使われても、ドキュメントの更新がされず、何が入っているか判らなくなる。
Re:予備項目 (スコア:1)
それはドキュメントのアップデートをきちんとしていないという、DBテーブルの設計が悪いこととは別の問題じゃないかな
項目が必要になるたびに本番でALTER TABLE叩くっていうのもそれはそれでリスクがあるわけだし、予備を定義しとくこと自体はそう間違いではないと思う
#逆に言うとどれだけ綺麗にDBテーブルの設計をしていても、改修に伴ってドキュメントのアップデートをきちんとしてなければ、それは「酷いDB」になるんだしさ
Re: (スコア:0)
「○○を保存するようにしたいけど、カラムがないですねぇ」→「△△が使ってませんから、そこに入れることにしましょう」なんていう、カラム名と中身がまったく一致していない状態に比べれば、予備の方が格段にマシです。
どことは言いませんがレセコンで… (スコア:0)
Oracle DBのレコードがvarchar2(256)の固定長。
アクセスは先頭からn文字が○○で、次のm文字が××で…。
そして、一月=1テーブル。
これでパフォーマンスを上げろと言われても。
というか、素直にCOBOLのままでええやん。
Re: (スコア:0)
バッチをCOBOLから .Net に移植したら処理時間が2倍になったあのレセコンですね?
Re: (スコア:0)
基本設計から作り直そうとしたけど大炎上、
でもサーバリプレースは必要だからとりあえず設計は現行のままでJava,JSP,SVF,Oracleでとりあえず構築しました
とか?
ああ・・・ (スコア:0)
テーブル名が半角全角英数スペース日本語入り乱れている。
本気で馬鹿かと思ったのは (スコア:0)
インデックスが張られていない
Re: (スコア:0)
プライマリキーすら無いよりマシ
Re: (スコア:0)
# 全部合わせて複合主キーなんだって
# 別の表は先頭32カラムだけが主キーだったけど、単にOracleの制限なだけで後ろのカラムも心の中では主キーなんだって
Re: (スコア:0)
プライマリキーなのに値が更新されるケースもあるね。プログラムやトリガーで関連テーブルを更新する羽目になってる
事もままある。
Re: (スコア:0)
フィールド (スコア:0)
うーん (スコア:0)
>ありとあらゆるデータが1つのテーブルに放り込まれており、また各行にどのようなデータが
>納められているかを区別するための列が設けられているというものだった
IPAの未踏か何かでそんなのを見たような見なかったような....
心が痛い (スコア:0)
ああ、Entity-Attribute-Value作っちゃったことあります。
めったに使わない部分だったせいかこの問題はスルーされて開発は進み、後で気付いたものの言い出せなくなり・・・
運用まで見守りましたが、その後どうなったのかは知りません。
Re:心が痛い (スコア:1)
俺も。だって客が項目動的に増やせるようにしたいとか言い出すから・・・会社的な事情により、システム自体がほぼ使われなくなったらしいので、犠牲者が出なかったことだけが幸い。
あれは動的にテーブル作っちゃえばよかったのかなぁorz
# さっきSQLアンチパターンの電子書籍版買ったとこなので、これからセルフ反省会。
Re:心が痛い (スコア:1)
うんうん。動的に項目を増やしたいときにはつかっちゃうよね。
Redmine のテーブルも、チケットのカスタム項目のところはそんな風になってる。
Re: (スコア:0)
俺も。
懺悔するしかない。ごめんなさい。
Re: (スコア:0)
XMLそのまま突っ込んで、取得後パースしていた私も同罪か・・・
Re:心が痛い (スコア:1)
これ見ると、準構造化ということでセフセフみたい、俺もやっている最中なので良かった
http://penguinlab.jp/wiki/SQL_%E3%82%A2%E3%83%B3%E3%83%81%E3%83%91%E3%... [penguinlab.jp]
Re: (スコア:0)
意図して作る分には良いんじゃないでしょうか。
多分JOINしまくるとまともな性能が出せないようなDBエンジンなのです。
現実として設計の美しさよりは性能が優先されますよね。
だから1つのテーブルに放り込んだ場合と、いくつもテーブルを参照してJOINした場合とで、
両者が全く同じ性能ならこんなことをやる人は減るでしょう。
「最近普及が進んでいる」とか言いますが, (スコア:0)
じつは dbm とか Berkeley DB あたりから引き継がれているデータベースだったりして…
COBOL? (スコア:0)
年月,1日,2日・・・,31日
みたいな感じのCOBOLから持ってきた感丸出しのテーブルとか。
あと、
>ありとあらゆるデータが1つのテーブルに放り込まれており
これで頭に浮かんだのはwordpressのテーブルだった
気持ちは判るが... (スコア:0)
・整合性制約を使わない設計なのにアプリ側のチェックがザル
・レコードの必須項目にNOT NULL制約をつけない
・設定テーブルがスキーマ定義+設定値みたいな構造になっている
見直しを提案したけど拒否られたので放置。もうどうなっても知らんw
Re: (スコア:0)
それでも最悪じゃないところが嫌になるよ。
俺の知ってるのは、上記2つの他
・カラム名が連番ベース
・どんなデータも固定長の文字列型(数値が左詰めったり、右詰めだったりする。しかも行ごとに違う)
今まだその現場に居るので (スコア:0)
詳しくか書けないが
SQLの断片とその用途が一対になったテーブルがある。
断片というのは、カラム名とかwhereの条件とか。
300カラムに主キー1つのテーブル (スコア:0)
最近かかわったプロジェクトで1テーブル300カラム以上のものがあった
既に2,3回程の改修が行われていたものに今回必要になるカラムを追加していった
Foo1,Bar1,Baz1,Foo2,Bar2,Baz3...が40くらい繰り返されているものが2パターン存在していて、明らかに使われていない
しかも主キーが数値型で1つしかない
便利なテーブルとしてなんでもかんでも詰め込み過ぎで正規化されていない
年配SEに再三テーブルの設計を見直しませんかと打診するが、昔から使っているから他に影響してはいけないし、今回はこのままでいきましょうというのだ
さらに、昔はExcelVBAでこのテーブルの値を読み書きしていて、この設計しかできなかったというのだ
頭が痛くならないうちに、必要な項目だけを抽出するSQL文とDtoとCriteriaを作って、見なかったことにした
Re: (スコア:0)
当時のExcelが256カラムしか(しか?)使えなかったという理由で、2テーブルに分けたOracleDBなら見たことがあります
#今のExcelはもっと使えます 念の為
##多カラムの推奨ではありません