JSONのEnum値をSQL CHECK制約に変換する

Enum検出と制約生成

JSONフィールドが固定セットの値（"active"、"inactive"、"suspended"など）を含む場合、コンバーターはカラムをそれらの値に制限するSQL制約を生成します。

JSON例

[
  { "id": 1, "name": "Alice", "status": "active", "role": "admin" },
  { "id": 2, "name": "Bob", "status": "inactive", "role": "editor" },
  { "id": 3, "name": "Carol", "status": "active", "role": "viewer" },
  { "id": 4, "name": "Dave", "status": "suspended", "role": "viewer" }
]

生成されるSQL（CHECK制約）

CREATE TABLE users (
  id SERIAL PRIMARY KEY,
  name VARCHAR(255) NOT NULL,
  status VARCHAR(20) NOT NULL,
  role VARCHAR(20) NOT NULL,
  CONSTRAINT chk_users_status CHECK (status IN ('active', 'inactive', 'suspended')),
  CONSTRAINT chk_users_role CHECK (role IN ('admin', 'editor', 'viewer'))
);

生成されるSQL（ENUM型 — MySQL/PostgreSQL）

-- PostgreSQL
CREATE TYPE user_status AS ENUM ('active', 'inactive', 'suspended');
CREATE TYPE user_role AS ENUM ('admin', 'editor', 'viewer');

CREATE TABLE users (
  id SERIAL PRIMARY KEY,
  name VARCHAR(255) NOT NULL,
  status user_status NOT NULL,
  role user_role NOT NULL
);

検出ロジック

コンバーターは以下の方法でenum候補を識別します：

1. 低カーディナリティ — すべてのサンプルレコードで10-15未満の一意な値を持つ文字列カラム。
2. 短い値 — 30文字未満の値（長い文字列は通常自由テキスト）。
3. 繰り返しパターン — 同じ値が複数のレコードに出現する。

CHECK vs ENUM

特徴	CHECK制約	ENUM型
移植性	すべてのデータベース	PostgreSQL、MySQL
値の追加	CHECKの変更	ALTER TYPE ADD VALUE（PG）
型安全性	カラムはVARCHARのまま	専用の型
順序	アルファベット順	定義順
複数テーブル	テーブルごとにCHECKを繰り返す	型を再利用

ベストプラクティスの推奨

• PostgreSQL — 再利用可能なenumにはCREATE TYPE ... AS ENUMを使用。
• MySQL — カラムレベルのENUM('a','b','c')またはCHECK制約（MySQL 8.0+）を使用。
• SQL Server — CHECK制約を使用（ネイティブENUMなし）。
• ポータブルSQL — すべての場所でCHECK制約を使用。

マイグレーションの考慮事項

CHECK制約に新しい値を追加するには、制約の置き換えが必要です：

ALTER TABLE users DROP CONSTRAINT chk_users_status;
ALTER TABLE users ADD CONSTRAINT chk_users_status
  CHECK (status IN ('active', 'inactive', 'suspended', 'archived'));

PostgreSQL ENUMはより簡単です — ALTER TYPE user_status ADD VALUE 'archived' — ただし値を削除することはできません。

使用しない場合

値のセットが頻繁に変更される場合やユーザー定義の場合（例：カスタムタグ）は、代わりにルックアップテーブルへの外部キーを使用してください。ENUM/CHECKは安定した、よく知られた値セットに最適です。