はじめに

実務でデータベースを覗いていると、1カラムにカンマ区切りの文字列が入っている場面を見かけます。

今回は、『SQLアンチパターン』の「ジェイウォーク（信号無視）」をベースに、実務で見かけるケースや設計の原則について整理しました。
「とりあえずカンマ区切りで入っている」というケースのレビュー時や、新規設計で迷った際の判断軸として参考にしていただければ幸いです。

この記事を読んで身につけられる観点

「INSERT が1回で済む」「画面表示が楽」
設計段階でそこまで意識しているケースは、私の経験では多くありません。
実際に見てきた動機は次のようなものです。

動機	よくある経緯
名残	Excel・CSV 取込のリストを、そのまま DB に入れた
後回し	プロトタイプで文字列に寄せ、中間テーブル化まで届かなかった
連携	外部システムのフォーマット（イベント ID と参加者 ID を1カラムに入れる等）をそのまま受け入れた
設定値	出力項目の並び・ヘッダー名など、「一覧っぽい設定」を1カラムにまとめた

いずれも 意図した正規化設計 というより、経路依存 で残っていることが多いです。
問題は「カンマ区切り自体」ではなく、リレーションで表すべきデータまで同じ形で入っているか です。

帳票・CSV エクスポート機能では、どの列を、どの順で、どのヘッダー名で出すか を設定として持つことがあります。

-- 例：エクスポートテンプレート設定
export_templates.header_columns = 'id,user_name,email,registered_at'

これは ユーザー同士の関係 ではなく、出力フォーマットのメタデータ です。個別のヘッダー名で JOIN 検索することも、外部キー整合性も通常不要なため、カンマ区切り（または JSON 配列）で持つ選択は現実的です。

要するに、検索・整合性が不要な設定・メタデータ に限れば、カンマ区切りも選択肢になります。業務上の関係性を表すデータまで同じ形にする必要はありません。

次のような要件があるなら、カンマ区切りではなく リレーション を選びます。

カンマ区切りは、DB に 配列を1カラムで持つ 手段の1つにすぎません。リレーションにしない場合、次の負担がついて回ります。

論点	何が起きるか
カラム桁数	要素が増えると `VARCHAR` が足りなくなる。上限見積もりと `ALTER` が発生しやすい
区切り文字	`,` 以外（`\|` 等）にしても、値自体にその文字が入ると破綻する。エスケープ規則が必要になる
クエリ	`split` / `LIKE` / 正規表現に依存し、INDEX が効きにくい
運用	「最大 N 個まで」をアプリ側の慣習で守る固定長に近い運用になり、レビューとテストのコストが上がる

今回SQLアンチパターンを読んで感じたのは、「業務として正しい状態を維持できるか？」を見るのが最も重要だということです。

多くのケースでリレーションを使ったほうがデータの整合性の観点では優れていると思いますが、どこでカンマ区切りのデータを許容するか？を考えるには、「現実の業務」や「プロジェクト特有の制約」を確認することが最優先です。

そのため、カンマ区切りについて検討する際は業務に詳しい有識者、DB設計に詳しい技術者など、さまざまな人たちと議論を深めることが安全にプロジェクトを進める上で重要です。