JSON to SQL

JSON array ko inferred column types wali CREATE TABLE aur batched INSERT statements mein badlein — PostgreSQL, MySQL, SQLite ya SQL Server ke liye.

JSON to SQL poori tarah aapke browser mein chalta hai. Aapka data device par convert hota hai aur kabhi upload nahin hota.

CSV to SQL converter kholein

JSON to SQL ke baare mein

JSON to SQL objects ka array leta hai — ek API response, ek export, ek fixture file — aur wo do statements produce karta hai jo ise database mein le jaate hain: ek CREATE TABLE jiske column types har column ki saari values se inferred hote hain, aur INSERTs jo multi-row VALUES lists mein batch hote hain. Type inference properly hoti hai: 32 bits paar karne wale integers BIGINT ban jaate hain, ISO-formatted strings TIMESTAMP ban jaate hain, mixed columns safely TEXT tak degrade hote hain, aur har canonical type target dialect ki spelling mein render hota hai — BOOLEAN MySQL mein TINYINT(1) aur SQL Server mein BIT ban kar aata hai. Wo details jo hand-written scripts todti hain exactly wo yahan target hain: identifiers dialect ke hisaab se quote hote hain taaki order naam ka column kabhi keyword se collide na kare, values ke andar single quotes correctly doubled hote hain taaki O’Brien jaise naam survive kar sakein, missing keys NULL ban jaate hain, aur nested objects JSON text ki tarah serialize hote hain.

Features

JSON to SQL kaise use karein

  1. Objects ka JSON array paste karein
  2. Table ka naam rakhein aur dialect chunein
  3. Zarurat ho toh rows-per-INSERT batch size adjust karein
  4. SQL copy karein — review ke liye types pehle list hote hain

Example

Input

[{"id":1,"name":"O'Brien","active":true}]

Output

CREATE TABLE "users" ("id" INTEGER, "name" TEXT, "active" BOOLEAN);
INSERT INTO "users" ("id", "name", "active") VALUES (1, 'O''Brien', TRUE);

O’’Brien ka doubled quote hi hai jo script ko valid rakhta hai.

Common errors aur troubleshooting

Aksar pooche jaane wale sawaal

JSON se column types kaise infer hote hain?
Column mein har value vote karti hai: whole numbers INTEGER dete hain (32 bits ke baad BIGINT), koi bhi decimal DOUBLE PRECISION banata hai, true/false BOOLEAN dete hain, ISO-dated strings TIMESTAMP dete hain, aur koi bhi conflict TEXT par settle hota hai. Saari rows scan hoti hain, isliye late float ek integer column ko corrupt nahin kar sakta.
SQL dialects ke beech kya change hota hai?
Identifier quoting (double quotes, backticks, brackets), type spellings (BOOLEAN vs TINYINT(1) vs BIT, DOUBLE PRECISION vs DOUBLE vs FLOAT vs REAL), boolean literals (TRUE vs 1), aur wo N-prefix jo SQL Server Unicode text par chahta hai.
Alag-alag keys wale objects kaise handle hote hain?
Columns saari rows ki keys ka union hote hain, first-seen order mein; jis row mein koi key missing hai wahan NULL insert hota hai. Heterogeneous API data ko table mein land karne ka usually yahi tareeka chahiye hota hai.
Kya generated script production-ready hai?
Ye import-ready hai: safe quoting aur sensible types. Ek production table ko phir bhi primary key, NOT NULL constraints aur indexes chahiye, jo koi bhi inference data se guess nahin kar sakti — pehle type list review karein, phir harden karein.

Related tools

Saare ArrayKit tools