JSON ～ SQL: ペイロードからクエリ可能なテーブルまで

タイプが JSON から SQL にマッピングされる方法

• 文字列 → `TEXT` (長さの予算がわかっている場合は `VARCHAR(n)`)。
• 特にお金の場合、浮動小数点ではなく整数→ `INTEGER` / `BIGINT`、小数→ `NUMERIC`。
• ブール値 → `BOOLEAN`。
• ネストされたオブジェクトと配列 → PostgreSQL では `JSONB`、MySQL 8 では `JSON` — または、データが存在する場合はそれらを子テーブルに正規化します。
• キーが欠落している → NULL 可能な列。値を偽装するデフォルトは決してありません。

生成されたテーブルは優れた出発点ですが、移行には非常に役立ちます。必要なスキーマを記述し、生成された SQL を列名と型の参照として使用します。

エスケープはオプションではありません

JSON の文字列には通常、アポストロフィ (`O’Brien`、`it's done`) が含まれており、手動で SQL に貼り付けると、文字列リテラルが早期に終了し、ステートメントが中断されます。生成された INSERT ステートメントは、すべての引用符を正しく 2 倍にします。これは、変換によって行われる最も便利な機能です。一括挿入の場合は、行を 1 つのステートメントにラップして、データベースが行ごとにコミットするのではなく書き込みをバッチ処理できるようにします。

良い使い方、悪い使い方

テスト用のフィクスチャ データ、API エクスポートのローカル スクラッチ コピー、デモ環境のシード、SQL での 1 回限りの質問への回答はすべて、JSON から SQL への変換の恩恵を受けます。運用スキーマ管理では必要ありません。移行にはレビュー、インデックス、制約、ロールバック パスが必要です。テーブルを生成し、出荷される移行を手書きします。

配列とオブジェクト: フラット化しますか、それとも保存しますか?

配列がスカラーの固定リストである場合、外部キーを持つ子テーブルによりクエリが単純になります。それが真に動的なペイロード (Webhook 本体、サードパーティのメタデータ) の場合は、次のように保存されます。`JSONB`そして、クエリするパスにインデックスを付けることが実用的な選択です。クエリの方法によって決定します。フィルタリングまたは結合するものはすべて列に属します。

ブラウザで実行してみる

データベースのエクスポートと API ダンプは、まさに未知のサービスにアップロードすべきではないペイロードです。ここでの JSON から SQL への変換は完全にページ内で行われるため、コピーしたステートメントはマシンから外部に流出することのないデータから構築されており、ツールはオフラインでも動作します。