はじめに
私自身、データベースというものを触り始めてから10年程度しかたっていないものでまだまだ未熟者です。
そんな私でもため息が出てしまうDB設計に出会ってしまうものです。
最初は特になにも思わなかったのにこんなことを思うようになったのは心が汚くなったか、成長したかのどちらかでしょう。
エクセルの項目そのままになっている
エクセルも確かに見た目がなのでそのままにしたい気持ちはわかります。
システム化する対象の元がLOOKUP系でリレーショナルに使いこなしているものをデータベース化したものであればまだよいのですが、大体はそのようにはなっていないでしょう。
よくある例がこんな感じでしょうか。
| id | 名前 | 商品1 | 商品2 | 商品3 |
|---|---|---|---|---|
| 1 | 太郎 | 0 | 0 | 0 |
商品追加されたらカラム増やすのか・・・? 要は正規化という考え方がうまくできていなかった時代があった、ということなのだろう。
型が適当
- なんでも文字列にしているパターン。
日付など20000101 というようにcharにしてしまっている。
大小比較などまぁできてしまうのだが、日付としての正当性の検証ができなくなってしまう。
- char varcharの使い分け
桁数が完全に固定でcharを使っているのはわかる。
欲を言えば検査制約がつけばよりよいだろう。
一方桁数が固定ではないのにcharを使っている、未設定に空白を使っている。
これはしんどい。
␣␣␣␣1などアプリケーションからすると何だこれという値が返ってくることは経験ないだろうか? 型が固定ではないならvarchar、未設定なのであればnullなど適切な型制約をつけるべきだろう。
外部キー制約がない
正規化の話にもやや関係するが、例えば商品コードなどといったものはシステムで一意であるものだろう。
それなのに各テーブルで独立した商品コードが存在してしまうと、データの整合性が取れなくなってしまうのは想像にたやすいだろう。
カラム名が独特すぎる
実例ではないがこんな感じ
顧客氏名→kkysmi (kokyakusimei)
わからない。
カラム名に名詞がついていない(もしくは省略されすぎていて想像力が必要)である場合のことである。
name とか customer_nameでいいだろう。。。
おわりに
色々書きましたが、当時制約などといった機能そのものがなかったりするかもしれないので致し方ない部分はあるでしょう。
大事なのは、こういった使い方に対して、「なんだこれ」と思うことだと思います。
そう思うということは今現在のRDBMSにおいてある程度適切な使い方をわかっているということなのでしょうから。