はじめに
実務でデータベースを覗いていると、1カラムにカンマ区切りの文字列が入っている場面を見かけます。
- タグ（
"React,TypeScript,Next.js"） -
CSV 出力設定のカラムヘッダー（
"id,name,email,created_at"） - イベント管理テーブルの複合キー風の値（例：
"101,202,303"）
今回は、『SQLアンチパターン』の「ジェイウォーク（信号無視）」をベースに、実務で見かけるケースや設計の原則について整理しました。
「とりあえずカンマ区切りで入っている」というケースのレビュー時や、新規設計で迷った際の判断軸として参考にしていただければ幸いです。
この記事を読んで身につけられる観点
- カンマ区切りを選びがちな理由と、その代償
- カンマ区切りで許容しやすいケース
- リレーションにすべきケース
カンマ区切りのデータを格納する理由
「INSERT が1回で済む」「画面表示が楽」
設計段階でそこまで意識しているケースは、私の経験では多くありません。
実際に見てきた動機は次のようなものです。
| 動機 | よくある経緯 |
|---|---|
| 名残 | Excel・CSV 取込のリストを、そのまま DB に入れた |
| 後回し | プロトタイプで文字列に寄せ、中間テーブル化まで届かなかった |
| 連携 | 外部システムのフォーマット（イベント ID と参加者 ID を1カラムに入れる等）をそのまま受け入れた |
| 設定値 | 出力項目の並び・ヘッダー名など、「一覧っぽい設定」を1カラムにまとめた |
いずれも 意図した正規化設計 というより、経路依存 で残っていることが多いです。
問題は「カンマ区切り自体」ではなく、リレーションで表すべきデータまで同じ形で入っているか です。
カンマ区切りデータとして推奨される一例
CSV 出力時のカラムヘッダー
帳票・CSV エクスポート機能では、どの列を、どの順で、どのヘッダー名で出すか を設定として持つことがあります。
-- 例：エクスポートテンプレート設定
export_templates.header_columns = 'id,user_name,email,registered_at'
これは ユーザー同士の関係 ではなく、出力フォーマットのメタデータ です。個別のヘッダー名で JOIN 検索することも、外部キー整合性も通常不要なため、カンマ区切り（または JSON 配列）で持つ選択は現実的です。
要するに、検索・整合性が不要な設定・メタデータ に限れば、カンマ区切りも選択肢になります。業務上の関係性を表すデータまで同じ形にする必要はありません。
リレーションにすべきケース
次のような要件があるなら、カンマ区切りではなく リレーション を選びます。
| 要件 | カンマ区切り | リレーション（中間テーブル等） |
|---|---|---|
tag = 'React' で検索 |
LIKE 依存、INDEX が効きにくい |
INDEX・JOIN で素直 |
| タグの名前変更 | 全行を文字列置換 |
tags テーブル1件更新 |
| 重複・ typo | アプリ側で防ぐ | UNIQUE 制約で防げる |
| 件数の増加 | カラム長・可読性が限界 | 行追加で対応 |
アンチパターン
-
タグを1カラムに連結 —
FIND_IN_SET/LIKE '%,React,%'はスケールしない - 複数 FK を1文字列 — 参照整合性が効かず、孤児データが増える
- 「とりあえず split すれば動く」 — 値にカンマが含まれると即破綻
- 十分検討せずに非正規化を選択
補足：配列データはそもそも扱いが難しい
カンマ区切りは、DB に 配列を1カラムで持つ 手段の1つにすぎません。リレーションにしない場合、次の負担がついて回ります。
| 論点 | 何が起きるか |
|---|---|
| カラム桁数 | 要素が増えると VARCHAR が足りなくなる。上限見積もりと ALTER が発生しやすい |
| 区切り文字 |
, 以外（| 等）にしても、値自体にその文字が入る と破綻する。エスケープ規則が必要になる |
| クエリ |
split / LIKE / 正規表現に依存し、INDEX が効きにくい
|
| 運用 | 「最大 N 個まで」をアプリ側の慣習で守る 固定長に近い運用 になり、レビューとテストのコストが上がる |
まとめ
今回SQLアンチパターンを読んで感じたのは、「業務として正しい状態を維持できるか？」を見るのが最も重要だということです。
多くのケースでリレーションを使ったほうがデータの整合性の観点では優れていると思いますが、どこでカンマ区切りのデータを許容するか？を考えるには、「現実の業務」や「プロジェクト特有の制約」を確認することが最優先です。
そのため、カンマ区切りについて検討する際は業務に詳しい有識者、DB設計に詳しい技術者など、さまざまな人たちと議論を深めることが安全にプロジェクトを進める上で重要です。
参考文献
- SQLアンチパターン 第2版（著：Bill Karwin 監訳：和田卓人 訳：児島修）