मुफ़्त SQL से JSON कनवर्टर

SQL → JSON रूपांतरण के बारे में

यह टूल SQL CREATE TABLE कथनों का विश्लेषण करता है और उन्हें JSON स्कीमा प्रारूप में रूपांतरित करता है। यह कॉलम नाम, डेटा प्रकार आदि निकालता है।

समर्थित SQL डेटा प्रकार

• INT / INTEGER · 32-बिट पूर्णांक मान
• VARCHAR(n) · अधिकतम लंबाई के साथ चर-लंबाई टेक्स्ट
• TEXT · असीमित लंबाई का टेक्स्ट
• BOOLEAN / BOOL · सत्य/असत्य मान
• DATE · समय के बिना कैलेंडर तिथियाँ
• TIMESTAMP · समय क्षेत्र समर्थन के साथ तिथि और समय
• DECIMAL(p,s) · सटीक दशमलव संख्याएँ

अक्सर पूछे जाने वाले प्रश्न

कौन से SQL डायलेक्ट समर्थित हैं?

यह कन्वर्टर MySQL, PostgreSQL, SQL Server और SQLite द्वारा उपयोग किए जाने वाले मानक SQL सिंटैक्स को संभालता है।

क्या यह जटिल बाधाओं को संभालता है?

कन्वर्टर NOT NULL, PRIMARY KEY, DEFAULT और बुनियादी प्रकार जानकारी पहचानता है। CHECK या FOREIGN KEY जैसी जटिल बाधाएँ सरलीकृत होती हैं।

क्या मैं JSON आउटपुट का सीधे उपयोग कर सकता हूँ?

हाँ! JSON आउटपुट पठनीयता के लिए फ़ॉर्मेट किया गया है और API स्कीमा, TypeScript इंटरफ़ेस या जनरेटर में उपयोग किया जा सकता है।

Schema, not data, what this tool does

This converter takes a SQL CREATE TABLE statement and emits JSON Schema: a description of the columns, types and basic constraints, suitable for API contracts, TypeScript-type generation, and document-store migrations. It does not convert INSERT rows or query result sets to JSON. Search interest in "SQL to JSON" splits roughly in half between those two needs; if you've arrived expecting row-to-object conversion, you'll want a different tool. The schema-conversion path is the developer-facing case: you have a table definition and want a structured description of its shape that another tool can consume.

A short history of SQL

SQL was designed at IBM's San Jose Research Laboratory in the early 1970s by Donald D. Chamberlin and Raymond F. Boyce. The original name was SEQUEL: Structured English Query Language, conceived as a higher-level interface to IBM's experimental relational database System R. The relational model itself had been published in 1970 by Edgar F. Codd; Chamberlin and Boyce's contribution was a syntax that ordinary analysts could read, modelled on natural English clauses (SELECT … FROM … WHERE …) rather than on Codd's algebraic symbols. Boyce (who would also lend his name to Boyce-Codd Normal Form) died in 1974 at age 26, before the language he co-invented saw commercial release. The name was changed to SQL in 1975 because of a trademark conflict with Hawker Siddeley's SEQUEL trademark, although the original "sequel" pronunciation persists in the United States alongside the international "ess-cue-ell."

ANSI standardised SQL in 1986 (SQL-86), ISO ratified an essentially identical version in 1987 as ISO/IEC 9075, and the standard has been revised every three to five years since: SQL-92 (still the baseline most tutorials assume), SQL:1999 (recursive queries, triggers), SQL:2003 (XML type, MERGE), SQL:2011 (temporal tables), SQL:2016 (JSON support), and most recently SQL:2023 (multi-dimensional arrays, property graph queries). Despite waves of competing technologies (object databases in the 1990s, NoSQL in the late 2000s, data lakes in the 2010s) SQL has persisted as the dominant query language for structured data for over fifty years. By 2024, even most NoSQL platforms have reintroduced SQL or SQL-like layers (Cassandra's CQL, MongoDB's $sql aggregation stage, DynamoDB's PartiQL, Spark SQL, Trino, DuckDB, BigQuery, Snowflake), confirming Mike Stonebraker's prediction that the language would outlive any single storage engine.

JSON in one paragraph

JSON (JavaScript Object Notation) was specified by Douglas Crockford in 2001, derived from a subset of JavaScript object literal syntax, and standardised as ECMA-404 in 2013 and IETF RFC 8259 in 2017. It has only six value types (string, number, boolean, null, array, object) and no native concept of dates, decimals, binary, or schemas. JSON Schema (a separate specification, currently at draft 2020-12) layers structural and type validation on top. The value of JSON Schema for this converter: it's a portable, schema-agnostic format that almost every modern code-generator and validation library understands.

The mechanical conversion

A representative input:

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

Maps to:

{
  "$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"]
}

Step by step: tokenise the input, locate CREATE TABLE and the table name, find the parenthesised column list, split column definitions on top-level commas (respecting nested parentheses for things like DECIMAL(10,2) or CHECK (x > 0)), parse each column into name + type + modifiers, and map the SQL type to the closest JSON Schema type. NOT NULL becomes membership in the required array. DEFAULT becomes a default value. PRIMARY KEY usually becomes an annotation or membership in required. CHECK, FOREIGN KEY, UNIQUE and indices typically become text annotations because JSON Schema has no direct equivalent.

The dialect problem

SQL is famously a family of dialects, not a single language. Even basic identifier quoting differs:

• MySQL / MariaDB: backticks: `column_name`.
• PostgreSQL and the SQL standard, double quotes: "column_name".
• SQL Server / MS Access: square brackets: [column_name].
• SQLite: permissive, accepts all three.

Type names diverge too. INT(11) in MySQL is a display-width hint that PostgreSQL rejects. SERIAL in PostgreSQL is shorthand for INT NOT NULL AUTO_INCREMENT PRIMARY KEY; IDENTITY fills the same role in SQL Server; SQLite uses AUTOINCREMENT. BOOLEAN is TINYINT(1) under the hood in MySQL. Geographic types (GEOMETRY, POINT), JSON column types (JSON, JSONB), array types (PostgreSQL's INTEGER[]) and full-text vector types (VECTOR(1536) in pgvector) have no JSON Schema equivalent and end up as opaque string annotations. BLOB and BYTEA binary data has no native JSON representation; standard practice is base64-stringification with a contentEncoding hint.

SQL types vs JSON types, the impedance mismatch

SQL has a rich type system; JSON has six value types and no schema. Worth knowing:

• Numeric types: INT, BIGINT, SMALLINT, TINYINT all collapse to JSON number. JavaScript and most JSON parsers use IEEE 754 double-precision, which only represents integers up to 2^53 exactly. BIGINT values above that lose precision when round-tripped through JSON parsers. Some pipelines serialise BIGINT as a quoted string to preserve precision; that's a known JSON-API design pattern.
• Decimal / numeric: DECIMAL(10,2) for money is an exact-precision type in SQL but becomes a lossy floating-point JSON number unless serialised as a string. Financial APIs almost always serialise money as decimal strings ("19.99") for this reason.
• Date / time / timestamp: JSON has no native temporal type. The standard convention is ISO 8601 strings ("2026-05-02T14:30:00Z"), with JSON Schema's { "type": "string", "format": "date-time" } annotation. TIMESTAMP WITH TIME ZONE in PostgreSQL preserves zone information; TIMESTAMP WITHOUT TIME ZONE doesn't, round-tripping through JSON usually flattens the distinction.
• Booleans: straightforward true / false mapping. SQL Server's BIT often comes through as 1/0; this converter normalises to true/false.
• NULL: JSON null. Worth noting that the absence of a key ({}) is semantically distinct from an explicit null ({"x": null}) in most JSON consumers.
• Enums: SQL ENUM('a','b','c') maps cleanly to JSON Schema {"enum": ["a","b","c"]}.

When you'd reach for this

• Generating OpenAPI / Swagger schemas from existing database tables for an API that returns the same shape.
• Bootstrapping TypeScript / Zod / io-ts types: once you have JSON Schema, tools like quicktype or json-schema-to-typescript produce type definitions automatically.
• Migrating SQL → MongoDB / Firestore / DynamoDB: the first artefact you usually want is a list of document shapes; JSON Schema is a clean intermediate format for that planning exercise.
• Frontend mocking: front-end engineers building against a backend that doesn't yet exist need a JSON description of the row shape so they can generate fake data with faker.js, MSW, or json-server.
• Internal data-dictionary documentation: DBT model docs, design wikis, schema-as-code repositories all consume JSON descriptions of table shapes.
• Test fixture generation: property-based testing libraries (hypothesis, fast-check) and factory libraries need a description of the expected shape to generate satisfying test data.

Modern alternatives

• Database-native JSON output. PostgreSQL has row_to_json(), json_agg() and the jsonb_ family; MySQL has JSON_OBJECT() and JSON_ARRAYAGG(); SQL Server has FOR JSON. If you control the database you can usually skip a converter entirely and emit JSON straight from the query.
• ORM introspection. Prisma, Drizzle, SQLAlchemy, TypeORM, Sequelize-auto and similar libraries can introspect existing tables and emit type definitions or schema files in their own formats, often closer to what you actually want than raw JSON Schema.
• Schema-as-code tools. Atlas (HCL), Liquibase (YAML), Sqitch (SQL), and DBML (Database Markup Language) describe table shapes in their own DSLs that have richer constraint vocabularies than JSON Schema.

More questions

What if my CREATE TABLE has FOREIGN KEY constraints?

JSON Schema doesn't have a native foreign-key concept. The cleanest representation is a custom annotation (e.g., a non-standard x-foreign-key property) noting the referenced table and column. This converter preserves the relationship as a text note in the output; if you need fully-formal reference modeling, JSON Schema's $ref + a separate definitions block is the closest fit, but it's awkward for many-to-many cases. For richer relational modeling consider DBML or Atlas HCL.

Why doesn't the output include CHECK constraints?

JSON Schema can express many simple CHECK constraints, CHECK (age >= 0) becomes {"minimum": 0}, CHECK (status IN ('a','b')) becomes {"enum": ["a","b"]}: but arbitrary SQL expressions in CHECK clauses (function calls, joins, subqueries) have no JSON Schema equivalent. The converter recognises the simple cases and preserves complex constraints as text annotations rather than silently dropping them.

Can I convert INSERT rows to JSON?

Not with this tool, it only handles schema-level conversion (CREATE TABLE). For row-level conversion, the right approach is usually database-native: PostgreSQL's SELECT row_to_json(t) FROM tbl t, MySQL's JSON_OBJECT(), or exporting to CSV and using a CSV-to-JSON tool. mysqldump --xml piped through an XML-to-JSON converter is another well-trodden path.

Why is BIGINT a problem in JSON?

JavaScript's JSON.parse uses IEEE 754 doubles, which can only represent integers up to 2^53 = 9,007,199,254,740,992 exactly. Numbers above that lose precision. SQL BIGINT goes up to 2^63 ≈ 9.2 quintillion, well beyond the safe JSON integer range. The cross-platform convention for safely transporting BIGINT through JSON is to serialise it as a string and parse with BigInt at the destination; many APIs (Twitter / X's tweet IDs, Stripe IDs, PostgreSQL's bigserial) do exactly this.

Does anything get sent to a server?

No. The parser runs in your browser; the JSON output is built locally. Pasted SQL never leaves your device, which matters if your CREATE TABLE statements contain proprietary column names, internal table conventions or other details you don't want logged. The page works offline once it's loaded.

संबंधित टूल