DBの汎用テーブルほど闇の深いものはない

汎用テーブルとは

誰が思いついたのか生まれてしまった、業の深いテーブルのことである

汎用・・・［名］(スル)いろいろの方面に広く用いること。「同一規格の部品を汎用する」

From コトバンク

つまり、 いろんなデータを格納できるテーブル のこと、または その設計

具体的例

こんなテーブル定義見たことないでしょうか？？

#	カラム名	データ型	備考
1 🔓	KEY	VARCHAR	キー値（検索用に使用）
2	NAME	VARCHAR	キーとその値に対応する名称
3	VAL	VARCHAR	キーに対応する値
4	DEL_FLG	CAHR(1)	論理削除フラグ
5	INSERT_DTM	DATETIME	システム挿入日付
6	UPDATE_DTM	DATETIME	システム更新日付

汎用って聞こえはいいけどさ・・・

汎用テーブルのデメリット

• 個別に切り出していないため、以下のデメリットがある
  • 該当のデータが どういった型であるのが望ましいのか、テーブル定義だけでは分からない
    • 仕様把握を困難にする
    • 思わぬエラーの原因となる
  • したがって以下の対応をしようとするケースが多い
    • 資料で頑張ってまとめて管理しようとする
      （※大概の場合、資料の更新が等閑になり、最終的に資料が消え去る）
    • View/Functionを使用して単一のテーブルかのように振舞わせる
      （※最初から個別テーブル化したほうが労力は少ないはず）

上記のデメリットが重なると、そのシステムの達人的な人に仕様知識が集中し、いずれ崩壊する
仕様が個人の知識に依存するような設計は全力で回避したほうがいい

(・・・自分がその会社に縛り付けられたいのであれば、話は別)

汎用テーブルのメリット

• 各種テーブルのキー値の説明用のテーブルとしては◎
  • というか、この用途に至っては __キー値の説明用のテーブル__に限って使用しているので厳密には汎用ではない
  • (私にはメリットが思いつきませんでした・・・誰か思いつく方はコメントください・・・ORZ)

まとめ

• テーブルは、 保持するデータの中身を明確に定義づけることが大切！！
  • テーブル名、カラム名が、データを表す名称になっていること
  • データ型がデータに即していて、 用途に適していること ≒ それ以外の用途に使用できない限定された型を使用すること
    • ex.)
      • 名前なら文字列型
      • 電話番号なら数値型
      • 誕生日なら日付型など