【DB】テーブル設計アンチパターン

業務システム開発を行う上でプログラミングだけでなくDB(データベース)操作も必須となります。
テーブル設計次第では記述するコードにも大きく影響を与えてしまうため正しい設計を行うことが大事です。
今回は業務でやってしまいがちなテーブル設計アンチパターンをいくつか紹介したいと思います。

テーブル設計アンチパターン

非スカラ値(ジェイウォーク)

説明
　正規化を行っていないデータが含まれている。
　カンマ区切りデータの格納、データ型に配列を使用。
問題
　取得データをアプリケーション側で加工しなければならない。
対応
　配列型を採用しない、正規化をちゃんと行う。

ダブルミーニング

説明
　「その他」列のような、様々な値が入ってくるような列を定義する。
問題
　取得したデータが何なのか分からない(アプリケーション側で判断しなければならない)。
対応
　値の種類ごとに列名を定義する。

単一参照テーブル(コードマスタ)

説明
　様々な体系のコードを1つのテーブルにまとめる。(コードマスタの作成)
問題
　レコードの増加によるパフォーマンスの劣化。
　ER図で見た時に可読性が落ちる。
対応
　マスタは個別に定義をおこなう。

テーブルの水平分割(メタデータトリブル)

説明
　名称違いで構造の同じテーブルを複数定義する。
　※例). 年度ごとに売上データを別テーブルに分割する。
問題
　複数のテーブルを跨いで検索する場合にクエリの修正が必要。
対応
　パーティショニングテーブルを採用する。

テーブルの垂直分割

説明
　カラムの多いテーブルを同じ主キーで複数定義する。
　※例). データ抽出のパフォーマンス向上のためデータを分割。
問題
　両方のテーブルのカラムが必要な場合結合する必要がある。
対応
　リアルタイム性を重視しないのデータ抽出であれば、
　カラムを絞り込んだマテリアライズドビューを採用する。

不適切なキー定義

説明
　可変長文字列型をキーとして設定する。
問題
　可変長文字列で不要な空白が混入していた場合に不具合が発生する。
対応
　キーには固定長文字列、数値型など不変な値を使用する。

IDリクワイアド

説明
　とりあえずテーブルにid列を定義する。
問題
　シーケンス=主キーではないので一意性が損なわれる。
対応
　サロゲートキーが必要な場合は別途キーを定義する。
　idではなく○○idのような明確な名前を使える。

キーレスエントリ

説明
　外部キー制約を使用しない。
問題
　参照整合性をアプリ側で担保する必要がある。
　壊れた参照データが残る可能性がある。
対応
　外部キー制約を使用する。
　※親テーブルのレコードを削除した際に子テーブルの参照元テーブルを自動削除するように定義する
　　 こともできる

マルチカラムアトリビュート

説明
　横持ちでカラムにデータを持つ。
問題
　データが増えるたびに列を増やす必要がある。
対応
　子テーブルに分割する。

まとめ

いくつかのアンチパターンを紹介しましたが、弊社でもアンチパターンとなっているテーブルは存在します。
業務上やむを得ずそのような設計になってしまう場合もあるかと思いますが、回避できるのにもかかわらず知らずに設計してしまうケースがほとんどです。
『SQLアンチパターン』という書籍には紹介しきれなかったものも数多く載っているので興味のある方は一読をオススメします。