パスワードを忘れた? アカウント作成
10740289 story
プログラミング

今まで見た中で最もひどいDBのテーブル設計は? 35

ストーリー by hylom
女将を呼べ 部門より
あるAnonymous Coward 曰く、

今まで見たもっともクソなテーブル設計というブログ記事が話題になっている。

ここで言及されている「クソなテーブル」は、ありとあらゆるデータが1つのテーブルに放り込まれており、また各行にどのようなデータが納められているかを区別するための列が設けられているというものだったそうだ。

見方を変えれば最近普及が進んでいるKey-Valueストア型データベースのようにも見えるが、通常のSQLデータベースでこのような使い方をするのは確かにひどい。

ちなみにこのような設計は、SQLアンチパターンにて「Entity-Attribute-Value」として紹介されている。

  • by Anonymous Coward on 2014年03月06日 18時00分 (#2557608)

    ありとあらゆるデータが1つのテーブルに放り込まれており、また各行にどのようなデータが納められているかを区別するための列が設けられている

    後半部は兎も角、前半部(=1つのテーブルで済ます)は、通常のSQLデータベースでもそういう使い方することあるよ
    殆どのフィールドを検索条件に用いることがあって、しかもテーブル全部見ないといけない検索をする時はそれが一番速いから
    設計としては美しくないかもしれないけど、実用上はそのほうがいい、ってことはある

    自分が見た中で一番酷かったのは、おそらくシステムの拡張への対応を手抜きするためだったんだろうけど、たとえば「電話番号」のフィールドに「携帯電話」を付け足して、「000-000-0000|000-0000-0000」みたいに「|で区切って格納すること」とかいう変な要件加えてる、みたいなDBかな。至るところにそういうフィールドが混在してるの

    関係ないけどDBのテスト用IDが「scott」ではなく「tiger」とだけ書かれていたので
    パスワードが「scott」なのかな、と思ったらログインできず、発行者に問い合わせたら「bunny」だったことはある
    「パスワード書かなくても類推できると思った」じゃねえよ馬鹿

    • 「パスワード書かなくても類推できると思った」じゃねえよ馬鹿

      腐った女子種目のタイ&バニの情報共有強要するのはセクハラだと訴えるべきところですね。

    • by Anonymous Coward

      POSレジの伝票テーブルで1レコードに128カラムも項目があって、行番0がヘッダレコードになっていて、明細項目が行番1以降にずらずら並んでいる。1伝票処理するのに馬鹿でかいレコードを複数処理しなければならない上に、ストアドプロシージャで簡単には処理できないデータ形式だったんで、大した処理ではないのにステップ数ばかりが増える。その上開発言語がVB2だったから地獄だった。

    • by Anonymous Coward

      そもそも、外部のデータフォーマットそのままだったりするしね。
      見易く整理するのも良いけど、ジャーナル的に使われていたりする生に近いデータだと、フォーマットを弄る方が後々祟ったりするし。

  • 自分で見たすごいのは、10000件位のデータ処理するのに、1レコードに30個くらいのサブレコードが定義されていて、データを30個ずつ分けて入れて300レコード位にしていた。 それを、集計したり、並べ替えをしたりするやつだった。 一件ずつにすれば1行で終わるような処理が二重ループ、三重ループになっていた。
    --
    -- 哀れな日本人専用(sorry Japanese only) --
  • by commonld (45958) on 2014年03月06日 18時54分 (#2557669) 日記
    見たいな感じでテーブル名カラム名に機種依存文字を...
  • by shuichi (572) on 2014年03月06日 19時03分 (#2557682) ホームページ 日記

    今後、項目が増えたときのために、
    "予備1", "予備2" ...
    という列が定義されている。

    実際、その項目が使われても、ドキュメントの更新がされず、何が入っているか判らなくなる。

    • by Anonymous Coward on 2014年03月06日 19時25分 (#2557700)

      それはドキュメントのアップデートをきちんとしていないという、DBテーブルの設計が悪いこととは別の問題じゃないかな
      項目が必要になるたびに本番でALTER TABLE叩くっていうのもそれはそれでリスクがあるわけだし、予備を定義しとくこと自体はそう間違いではないと思う

      #逆に言うとどれだけ綺麗にDBテーブルの設計をしていても、改修に伴ってドキュメントのアップデートをきちんとしてなければ、それは「酷いDB」になるんだしさ

    • by Anonymous Coward

      「○○を保存するようにしたいけど、カラムがないですねぇ」→「△△が使ってませんから、そこに入れることにしましょう」なんていう、カラム名と中身がまったく一致していない状態に比べれば、予備の方が格段にマシです。

  • by Anonymous Coward on 2014年03月06日 17時58分 (#2557605)

    Oracle DBのレコードがvarchar2(256)の固定長。
    アクセスは先頭からn文字が○○で、次のm文字が××で…。
    そして、一月=1テーブル。

    これでパフォーマンスを上げろと言われても。
    というか、素直にCOBOLのままでええやん。

    • by Anonymous Coward

      バッチをCOBOLから .Net に移植したら処理時間が2倍になったあのレセコンですね?

    • by Anonymous Coward

      基本設計から作り直そうとしたけど大炎上、
      でもサーバリプレースは必要だからとりあえず設計は現行のままでJava,JSP,SVF,Oracleでとりあえず構築しました

      とか?

  • by Anonymous Coward on 2014年03月06日 18時06分 (#2557617)

    テーブル名が半角全角英数スペース日本語入り乱れている。

  • by Anonymous Coward on 2014年03月06日 18時11分 (#2557622)

    インデックスが張られていない

    • by Anonymous Coward

      プライマリキーすら無いよりマシ

      • by Anonymous Coward
        プライマリキーしかないよりマシ
        # 全部合わせて複合主キーなんだって
        # 別の表は先頭32カラムだけが主キーだったけど、単にOracleの制限なだけで後ろのカラムも心の中では主キーなんだって
      • by Anonymous Coward

        プライマリキーなのに値が更新されるケースもあるね。プログラムやトリガーで関連テーブルを更新する羽目になってる
        事もままある。

    • by Anonymous Coward
      テストでは問題なかったけど、本番で10分間レスポンスがなくて発覚…
  • by Anonymous Coward on 2014年03月06日 18時20分 (#2557627)
    緯度経度のフィールドが、度、分、秒、秒少数点 に分けられてた。 データサンプルが 35.12.10.4 とかだったから?? サンプルが35/12/10.4って書いてあったらまた違ってたんだろうな...
  • by Anonymous Coward on 2014年03月06日 18時21分 (#2557628)

    >ありとあらゆるデータが1つのテーブルに放り込まれており、また各行にどのようなデータが
    >納められているかを区別するための列が設けられているというものだった

    IPAの未踏か何かでそんなのを見たような見なかったような....

  • by Anonymous Coward on 2014年03月06日 18時28分 (#2557637)

    ああ、Entity-Attribute-Value作っちゃったことあります。
    めったに使わない部分だったせいかこの問題はスルーされて開発は進み、後で気付いたものの言い出せなくなり・・・
    運用まで見守りましたが、その後どうなったのかは知りません。

    • by Anonymous Coward on 2014年03月06日 18時53分 (#2557667)

      俺も。だって客が項目動的に増やせるようにしたいとか言い出すから・・・会社的な事情により、システム自体がほぼ使われなくなったらしいので、犠牲者が出なかったことだけが幸い。
      あれは動的にテーブル作っちゃえばよかったのかなぁorz

      # さっきSQLアンチパターンの電子書籍版買ったとこなので、これからセルフ反省会。

    • by Anonymous Coward

      俺も。
      懺悔するしかない。ごめんなさい。

    • by Anonymous Coward

      XMLそのまま突っ込んで、取得後パースしていた私も同罪か・・・

    • by Anonymous Coward

      意図して作る分には良いんじゃないでしょうか。
      多分JOINしまくるとまともな性能が出せないようなDBエンジンなのです。
      現実として設計の美しさよりは性能が優先されますよね。
      だから1つのテーブルに放り込んだ場合と、いくつもテーブルを参照してJOINした場合とで、
      両者が全く同じ性能ならこんなことをやる人は減るでしょう。

  • by Anonymous Coward on 2014年03月06日 18時47分 (#2557659)

    じつは dbm とか Berkeley DB あたりから引き継がれているデータベースだったりして…

  • by Anonymous Coward on 2014年03月06日 19時57分 (#2557732)

    年月,1日,2日・・・,31日
    みたいな感じのCOBOLから持ってきた感丸出しのテーブルとか。

    あと、
    >ありとあらゆるデータが1つのテーブルに放り込まれており
    これで頭に浮かんだのはwordpressのテーブルだった

  • by Anonymous Coward on 2014年03月06日 20時01分 (#2557735)

    ・整合性制約を使わない設計なのにアプリ側のチェックがザル
    ・レコードの必須項目にNOT NULL制約をつけない
    ・設定テーブルがスキーマ定義+設定値みたいな構造になっている

    見直しを提案したけど拒否られたので放置。もうどうなっても知らんw

    • by Anonymous Coward

      それでも最悪じゃないところが嫌になるよ。

      俺の知ってるのは、上記2つの他

      ・カラム名が連番ベース
      ・どんなデータも固定長の文字列型(数値が左詰めったり、右詰めだったりする。しかも行ごとに違う)

  • by Anonymous Coward on 2014年03月06日 20時07分 (#2557743)

    詳しくか書けないが

    SQLの断片とその用途が一対になったテーブルがある。
    断片というのは、カラム名とかwhereの条件とか。

  • by Anonymous Coward on 2014年03月06日 20時18分 (#2557754)

    最近かかわったプロジェクトで1テーブル300カラム以上のものがあった
    既に2,3回程の改修が行われていたものに今回必要になるカラムを追加していった
    Foo1,Bar1,Baz1,Foo2,Bar2,Baz3...が40くらい繰り返されているものが2パターン存在していて、明らかに使われていない
    しかも主キーが数値型で1つしかない
    便利なテーブルとしてなんでもかんでも詰め込み過ぎで正規化されていない

    年配SEに再三テーブルの設計を見直しませんかと打診するが、昔から使っているから他に影響してはいけないし、今回はこのままでいきましょうというのだ
    さらに、昔はExcelVBAでこのテーブルの値を読み書きしていて、この設計しかできなかったというのだ

    頭が痛くならないうちに、必要な項目だけを抽出するSQL文とDtoとCriteriaを作って、見なかったことにした

    • by Anonymous Coward

      当時のExcelが256カラムしか(しか?)使えなかったという理由で、2テーブルに分けたOracleDBなら見たことがあります

      #今のExcelはもっと使えます 念の為
      ##多カラムの推奨ではありません

typodupeerror

皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー

読み込み中...