今回からは論理設計のアンチパターンについて。
やってはいけない設計のパターンですね。これはまわりがやっていると気づかずにやっている可能性があるのでしっかりメモしておきたいです。
非スカラ系の値
これはテーブルに配列の値が入っているものです。
例としては下記のようなテーブルです。
| 社員ID | 社員名 | 子 |
|---|---|---|
| 001 | 山田 | 太郎 次郎 |
| 002 | 鈴木 | 太郎 次郎 三郎 |
こういったパターンは見たことがないですね。ただテーブルの中にカンマやアンスコ区切りで複数の値を入れているのをみたことはあるので概念としては同じかもしれないです。しかもSQLのデータ構造として配列型というものがあるらしいですね・・・使ったことはありませんが。
原則としては「配列型は使わない。第一正規系を使う」というのが正しい考え方のようです。
また人名のようなものはなるべ分割していれたほうがあとあと楽ですね。分割→結合は楽ですが、結合→分割は大変だからです。情報は意味を壊さない程度に分割して保存するようにしましょう。
ダブルミーニング
| ID | 名 | 列1 |
|---|---|---|
| 001 | 山田 | 170 |
| 002 | 鈴木 | 50 |
ダブルミーニングとは一つの列で別の意味をもたせることです。001番は列1は身長で、002は体重みたいな。ここまで露骨なものはさすがに見たことはないのですが、大局的に意味が近いものはやろうかなとおもったことはありましたね・・・(汗)
プログラマが変数を使うようにテーブルの列を変数とみなすことでこのようなことが生まれるケースがあるようです。
列は変数ではなく、一度意味を決めたら変更不可にしましょう。
単一参照テーブル
| コードタイプ | コード | コード名 |
|---|---|---|
| com_cd | C001 | A商事 |
| com_cd | C002 | B商事 |
| pref_cd | P001 | 北海道 |
単一参照テーブルというのはテーブル数を少なくするという意図で複数のマスタを同一テーブルで管理するという手法のようです。
オブジェクト指向の多態性の考え方をテーブルに持ち込んだもののようですね。
メリットとデメリットをまとめると以下のようになります。
メリット
- マスタテーブルの数がへるため、ER図やスキーマがシンプル
- コード検索のSQLを共通化できる
デメリット
- データの長さを大きめにとっておく必要がある
- レコード数が大きくなりパフォーマンスに悪影響がでる
- コードのSQLでコートタイプやコード値を間違えてもエラーにならず、バグに気づきにくい
基本的にはしないようがいいようですね。テーブルに多態性を持ち込んではいけないようです。
