9.7　共通カラムをうまく扱うには

データベースのテーブル設計において、運用の観点からテーブル横断的に追加する共通項目を用意することがあります。多くの場合、それらを指して「共通カラム」または「システムカラム」と呼びます。本書では「共通カラム」と呼称します。

9.7.1　共通カラムでよく利用される項目

たとえば多くの場合、以下のような項目が設定されます。

  • 作成日時（ created_at ）

  • 作成ユーザーID（ created_by ）

  • 作成トレースID（ created_trace_id ）

  • 更新日時（ updated_at ）

  • 更新ユーザーID（ updated_by ）

  • 更新トレースID（ updated_trace_id ）

  • リビジョン番号（ revision ）

場合によっては作成プログラムID、更新プログラムIDといった項目を追加する流派もあるでしょう。そこまで必要か？ という気もしますが、たとえばファイルインタフェースの到着で起動するバッチ処理と時間起動でのバッチ処理など、複数のバッチ処理が同一テーブルを更新することがある場合に、それらを区別したい場合があります。

共通カラムの種類が増えてくると、本来のビジネスドメインで利用するカラム数より大きくなってしまうことも多く、やや冗長に感じてしまいます。視認性の悪さ以外にも、データベース操作の性能にとってもマイナスでしょう。

一方でこれらの冗長性は、時として予期せぬトラブルに備える命綱となり得ます。システムが扱うドメイン次第ではありますが、万が一の場合に備えて、作成日時・更新日時の2項目程度は付与した方が良いでしょう。アプリケーションのログに出力すれば本質的にはデータベースへ保存しておく必要はないという意見もあります。ですが多くの場合、障害には緊急で対応する必要があります。あらかじめ調査や復旧の負荷をなるべく下げるような構成にしておくことは、悪い手ではありません。もちろん障害を出さないように全力を注ぐべきですが、一方で不具合が出た場合の次善の策も練っておきましょう。 ...