Konverter SQL ke JSON Gratis

Konversi pernyataan SQL CREATE TABLE ke skema JSON. Ekstrak nama kolom, tipe, dan kendala secara seketika.

Data Anda tidak pernah meninggalkan perangkat

Tentang konversi SQL → JSON

Alat ini menguraikan pernyataan SQL CREATE TABLE dan mengonversinya ke format skema JSON. Ia mengekstrak nama kolom, tipe data (INT, VARCHAR, TEXT, BOOLEAN, DATE, TIMESTAMP, DECIMAL), dan kendala (NOT NULL, PRIMARY KEY, nilai DEFAULT). Keluaran JSON cocok untuk dokumentasi API, desain basis data, atau alat migrasi.

Tipe data SQL yang didukung

Pertanyaan umum

Dialek SQL apa yang didukung?

Konverter ini menangani sintaks SQL standar yang digunakan oleh MySQL, PostgreSQL, SQL Server, dan SQLite. Fitur khusus dialek mungkin tidak sepenuhnya dikenali.

Apakah menangani kendala kompleks?

Konverter mengenali NOT NULL, PRIMARY KEY, DEFAULT, dan informasi tipe dasar. Kendala kompleks seperti CHECK atau FOREIGN KEY disimpan sebagai anotasi teks.

Bisakah saya menggunakan keluaran JSON secara langsung?

Ya! Keluaran JSON diformat untuk keterbacaan dan dapat digunakan dalam skema API, antarmuka TypeScript, atau generator dokumentasi.

Skema, bukan data, apa yang dilakukan alat ini

Konverter ini mengambil pernyataan SQL CREATE TABLE dan mengeluarkan JSON Schema: deskripsi kolom, tipe, dan constraint dasar, yang cocok untuk kontrak API, pembuatan tipe TypeScript, dan migrasi document-store. Alat ini tidak mengonversi baris INSERT atau kumpulan hasil query ke JSON. Minat pencarian dalam «SQL to JSON» terbagi kurang lebih menjadi dua antara dua kebutuhan tersebut; jika Anda tiba dengan mengharapkan konversi baris-ke-objek, Anda membutuhkan alat yang berbeda. Jalur konversi skema adalah kasus yang menghadap developer: Anda memiliki definisi tabel dan menginginkan deskripsi terstruktur dari bentuknya yang dapat dikonsumsi oleh alat lain.

Sejarah singkat SQL

SQL dirancang di Laboratorium Riset San Jose IBM pada awal tahun 1970-an oleh Donald D. Chamberlin dan Raymond F. Boyce. Nama aslinya adalah SEQUEL: Structured English Query Language, yang dikonsepkan sebagai antarmuka tingkat tinggi untuk basis data relasional eksperimental IBM System R. Model relasional itu sendiri telah dipublikasikan pada tahun 1970 oleh Edgar F. Codd; kontribusi Chamberlin dan Boyce adalah sintaks yang dapat dibaca oleh analis biasa, dimodelkan berdasarkan klausa bahasa Inggris alami (SELECT … FROM … WHERE …) daripada simbol aljabar Codd. Boyce (yang juga akan memberikan namanya pada Boyce-Codd Normal Form) meninggal pada tahun 1974 pada usia 26 tahun, sebelum bahasa yang ikut ditemukannya dipasarkan secara komersial. Nama tersebut diubah menjadi SQL pada tahun 1975 karena konflik merek dagang dengan merek dagang SEQUEL milik Hawker Siddeley, meskipun pengucapan «sequel» asli tetap digunakan di Amerika Serikat bersamaan dengan pengucapan internasional «ess-cue-ell».

ANSI menstandarisasi SQL pada tahun 1986 (SQL-86), ISO meratifikasi versi yang pada dasarnya identik pada tahun 1987 sebagai ISO/IEC 9075, dan standar tersebut telah direvisi setiap tiga hingga lima tahun sejak itu: SQL-92 (masih menjadi baseline yang diasumsikan sebagian besar tutorial), SQL:1999 (recursive query, trigger), SQL:2003 (tipe XML, MERGE), SQL:2011 (tabel temporal), SQL:2016 (dukungan JSON), dan yang terbaru SQL:2023 (array multi-dimensi, query property graph). Meskipun ada gelombang teknologi pesaing (basis data objek di tahun 1990-an, NoSQL di akhir 2000-an, data lake di tahun 2010-an), SQL telah bertahan sebagai bahasa query dominan untuk data terstruktur selama lebih dari lima puluh tahun. Pada tahun 2024, bahkan sebagian besar platform NoSQL telah memperkenalkan kembali lapisan SQL atau mirip-SQL (CQL Cassandra, tahap agregasi $sql MongoDB, PartiQL DynamoDB, Spark SQL, Trino, DuckDB, BigQuery, Snowflake), mengkonfirmasi prediksi Mike Stonebraker bahwa bahasa ini akan bertahan lebih lama dari mesin penyimpanan mana pun.

JSON dalam satu paragraf

JSON (JavaScript Object Notation) ditentukan oleh Douglas Crockford pada tahun 2001, diturunkan dari subset sintaks literal objek JavaScript, dan distandardisasi sebagai ECMA-404 pada tahun 2013 dan IETF RFC 8259 pada tahun 2017. JSON hanya memiliki enam tipe nilai (string, number, boolean, null, array, object) dan tidak ada konsep native untuk tanggal, desimal, biner, atau skema. JSON Schema (spesifikasi terpisah, saat ini pada draft 2020-12) melapisi validasi struktural dan tipe di atasnya. Nilai JSON Schema untuk konverter ini: ini adalah format portabel dan schema-agnostic yang dipahami oleh hampir semua code-generator modern dan pustaka validasi.

Konversi mekanikal

Contoh input yang representatif:

CREATE TABLE users (
  id INT PRIMARY KEY,
  email VARCHAR(255) NOT NULL,
  signup_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  is_active BOOLEAN DEFAULT TRUE
);

Dipetakan ke:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "users",
  "type": "object",
  "properties": {
    "id": { "type": "integer" },
    "email": { "type": "string", "maxLength": 255 },
    "signup_at": { "type": "string", "format": "date-time" },
    "is_active": { "type": "boolean", "default": true }
  },
  "required": ["id", "email"]
}

Langkah demi langkah: tokenisasi input, temukan CREATE TABLE dan nama tabel, temukan daftar kolom dalam tanda kurung, pisahkan definisi kolom pada koma level atas (menghormati tanda kurung bersarang untuk hal-hal seperti DECIMAL(10,2) atau CHECK (x > 0)), parse setiap kolom menjadi nama + tipe + modifier, dan petakan tipe SQL ke tipe JSON Schema terdekat. NOT NULL menjadi keanggotaan dalam array required. DEFAULT menjadi nilai default. PRIMARY KEY biasanya menjadi anotasi atau keanggotaan dalam required. CHECK, FOREIGN KEY, UNIQUE, dan indeks biasanya menjadi anotasi teks karena JSON Schema tidak memiliki padanan langsung.

Masalah dialek

SQL terkenal sebagai keluarga dialek, bukan bahasa tunggal. Bahkan pengutipan identifier dasar pun berbeda:

Nama tipe juga berbeda-beda. INT(11) di MySQL adalah petunjuk lebar tampilan yang ditolak PostgreSQL. SERIAL di PostgreSQL adalah singkatan dari INT NOT NULL AUTO_INCREMENT PRIMARY KEY; IDENTITY mengisi peran yang sama di SQL Server; SQLite menggunakan AUTOINCREMENT. BOOLEAN secara internal adalah TINYINT(1) di MySQL. Tipe geografis (GEOMETRY, POINT), tipe kolom JSON (JSON, JSONB), tipe array (INTEGER[] di PostgreSQL), dan tipe vektor full-text (VECTOR(1536) di pgvector) tidak memiliki padanan JSON Schema dan berakhir sebagai anotasi string buram. Data biner BLOB dan BYTEA tidak memiliki representasi JSON native; praktik standar adalah base64-stringification dengan petunjuk contentEncoding.

Tipe SQL vs tipe JSON, ketidakcocokan impedansi

SQL memiliki sistem tipe yang kaya; JSON memiliki enam tipe nilai dan tanpa skema. Hal yang perlu diketahui:

Kapan Anda membutuhkan ini

Alternatif modern

Pertanyaan Lebih Lanjut

Bagaimana jika CREATE TABLE saya memiliki constraint FOREIGN KEY?

JSON Schema tidak memiliki konsep foreign-key native. Representasi yang paling bersih adalah anotasi kustom (mis., properti non-standar x-foreign-key) yang mencatat tabel dan kolom yang direferensikan. Konverter ini mempertahankan hubungan sebagai catatan teks dalam output; jika Anda memerlukan pemodelan referensi yang sepenuhnya formal, $ref JSON Schema + blok definisi terpisah adalah yang paling mendekati, tetapi itu canggung untuk kasus many-to-many. Untuk pemodelan relasional yang lebih kaya, pertimbangkan DBML atau Atlas HCL.

Mengapa output tidak menyertakan constraint CHECK?

JSON Schema dapat mengekspresikan banyak constraint CHECK sederhana, CHECK (age >= 0) menjadi {"minimum": 0}, CHECK (status IN ('a','b')) menjadi {"enum": ["a","b"]}: tetapi ekspresi SQL arbitrer dalam klausa CHECK (pemanggilan fungsi, join, subquery) tidak memiliki padanan JSON Schema. Konverter mengenali kasus-kasus sederhana dan mempertahankan constraint kompleks sebagai anotasi teks daripada menghapusnya secara diam-diam.

Bisakah saya mengonversi baris INSERT ke JSON?

Tidak dengan alat ini, hanya menangani konversi tingkat skema (CREATE TABLE). Untuk konversi tingkat baris, pendekatan yang tepat biasanya database-native: SELECT row_to_json(t) FROM tbl t di PostgreSQL, JSON_OBJECT() di MySQL, atau ekspor ke CSV dan menggunakan alat CSV-to-JSON. mysqldump --xml yang di-pipe melalui konverter XML-to-JSON adalah jalur lain yang sudah teruji.

Mengapa BIGINT bermasalah dalam JSON?

JSON.parse JavaScript menggunakan double IEEE 754, yang hanya dapat merepresentasikan bilangan bulat hingga 2^53 = 9.007.199.254.740.992 secara tepat. Angka di atas itu kehilangan presisi. SQL BIGINT mencapai 2^63 ≈ 9,2 kuintiliun, jauh melampaui rentang bilangan bulat JSON yang aman. Konvensi lintas platform untuk mengangkut BIGINT dengan aman melalui JSON adalah men-serialisasi-nya sebagai string dan mem-parse dengan BigInt di tujuan; banyak API (ID tweet Twitter / X, ID Stripe, bigserial PostgreSQL) melakukan persis ini.

Apakah ada yang dikirim ke server?

Tidak. Parser berjalan di browser Anda; output JSON dibuat secara lokal. SQL yang ditempel tidak pernah meninggalkan perangkat Anda, yang penting jika pernyataan CREATE TABLE Anda mengandung nama kolom proprietary, konvensi tabel internal, atau detail lain yang tidak ingin Anda catat. Halaman ini bekerja offline setelah dimuat.

Alat terkait

Pemformat JSON

Format, minifikasi, dan validasi JSON secara seketika.

Pemformat SQL

Format dan perindah kueri SQL.

Pemformat XML

Format dan validasi dokumen XML.