コードマスタとは？
| 分類CD | コード | 名称 | ソート順 |
|---|---|---|---|
| 'GENDER' | 1 | '男性' | 1 |
| 'GENDER' | 2 | '女性' | 2 |
| 'STATUS' | 1 | '未登録' | 1 |
| 'STATUS' | 2 | '登録済み' | 2 |
| 'STATUS' | 3 | '更新中' | 3 |
| 上記のようなコードを一まとめに定義したテーブルのことです。 |
書くきっかけ
社内でコードマスタを使う以外の方法は、ないのだろうか？ と必死に考え相談した結果
運用や保守、全体を考えると、コードマスタが一番よいという結果になりました。
それの備忘録として書きます。
コードマスタを使う大きなメリット
- コードの名称変更や追加の場合、コードマスタの修正のみで対応できる
- テーブルの数を減らすことができ、ER図やテーブル設計書を簡単にできる。
問題点１: DB(コードマスタ)と実装内の2重管理
コードマスタで定義したコードで、分岐処理等を実装で書くと、DB(コードマスタ)と実装内の2重管理となってしまう。
解決策として、実装内の列挙型Enumで定義する方法があります。
でも下記のデメリットがあります。
- コードの変更や追加する際は、再デプロイが必要
- データベースしか見れない人は、性別コードの1が何か分からない。
- 性別名称も含めて出力したい時は、実装で加工する必要がある。(CSV, EXCEL出力等)
業務アプリケーションはデータありきのシステムであることが多く、データの定義が実装とDBに分かれるのは良くない。
参考: Rails脱初心者のための基礎知識と実装Tipsまとめ(2) - 区分値管理編 - Qiita
コードマスタを使って下記のように対応。
⇒判定に必要なコードのみ定数クラスで定義して、その定数に修正が入った場合は実装も併せて修正する
問題点２: 複数コードをまとめて1テーブルに定義
-
データ量が多くなると、パフォーマンスが悪い。
どんな値でも入るように、型を大きめに定義する必要がある。 -
分類CDのコピペミス等でもエラーにならず、バグに気づきにくい。
SELECT *
FROM X
LEFT JOIN CODE_MASTER CM1
ON CM1 = 'GENDER'
AND X.gender = CM1.CODE
LEFT JOIN CODE_MASTER CM2
ON CM2 = 'GENDER'
AND X.status = CM2.CODE
原則でいうと、一つのコードごとにテーブルを分けて定義するものだと思います。
上記のデメリットとコードマスタのメリットである、テーブル数を減らすことを比較すると
パフォーマンスに問題がある場合を除いて、メリットの方が大きい。
コードマスタを使って下記のように対応。
⇒コードマスタを起因とするバグは、単体テストで必ず発見する。
コードマスタでなんでも対応しようとせず、コードマスタ対応外の場合は別テーブルを作成する。
(データ量が多い、汎用カラム等は作らない。)
参考: 第3回 テーブル設計のグレーゾーン～毒と薬は紙一重 （1）単一参照テーブル～テーブルにポリモフィズムは必要か
まとめ
コードマスタのデメリットを無くそうすると、コードマスタの大きなメリットが失われてデメリットの方が大きくなる。だからコードマスタを使う。