
【DB設計】『達人に学ぶDB設計徹底指南書』に学ぶ、アンチパターン
はじめに データベースの設計は基本設計の中でもかなり重要な工程です。特にデータの構造によってアプリケーションが決まるため、データベース設計での失敗をアプリケーションで改善することはできません。今回は『達人に学ぶDB設計徹底指南書』で指摘されているアンチパターンをピックアップして紹介します。 アンチパターン 非スカラ値の格納(第一正規形未満) 【症状】第一正規形はデータベースの原則である、テーブルに含まれるすべての値がスカラ値であるという原則を無視した「複数の値」をセルにいれること 【なぜ起こるか?】開発者がRDBに柔軟なデータ型が欲しくなり、実装してしまった…など 【問題点】 【対策】 ダブルミーニング 【症状】value カラムには「身長」と「体重」の両方入っている 【なぜ起こるか?】途中からvalueカラム(身長)が不要となり、「体重」が必要となったため、列の使い回ししたくなった…など 【問題点】 【対策】 単一参照テーブル 【症状】部署や会社といった別の意味を持つものを構造的に似ているということで一つのテーブルにまとめてしまう。 【なぜ起こるか?】数百テーブルがある状況において、同じ構造を持ったテーブルを一つのテーブルにまとめることで効率化を図った…など 【問題点】 【対策】 テーブル分割 水平分割 【症状】レコード単位でテーブルを分割してしまうこと例えば2010年用のテーブルと2011年用のテーブルなど、、、業務系のトランザクションテーブルに多い 【なぜ起こるか?】何百万〜何十億とレコードが積み重なったときI/Oコストの増大が発生し、そのパフォーマンス改善を狙って分割してしまう 【問題点】 【対策】 垂直分割 【症状】列を軸にテーブルを分割してしまうこと例えば、社員テーブルを「社員ID・年齢」と「社員ID・名前・部署コード」といった形で分割してしまう。 【なぜ起こるか?】I/Oがボトルネックになったときのパフォーマンス改善として、実装されてしまう。 【問題点】 【対策】 最後に これまで紹介させていただいたアンチパターンは、自分自身も実際に現場で目にした例も多かったです。そして、バックエンドエンジニアとして業務経験が浅かった頃は、1列に集約関数実行後の値をjson文字列で格納した変なサマリーテーブルを作ったことも有りました。。。そのような実装をしてしまう前にアンチパターンを知っておくことで事故を防ぎ、今後の保守や運用の効率が上がって行くかと思います。この記事が少しでも皆さんの設計のヒントになれば嬉しいです! 参考文献