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

SQL CREATE TABLE स्टेटमेंट को JSON स्कीमा में कनवर्ट करें। कॉलम नाम, प्रकार और बाधाओं को तुरंत निकालें।

आपका डेटा कभी आपके डिवाइस से नहीं जाता

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

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

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

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

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

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

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

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

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

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

Schema, data नहीं: यह tool क्या करता है

यह converter एक SQL CREATE TABLE statement लेता है और JSON Schema emit करता है: columns, types और basic constraints का एक description, API contracts, TypeScript-type generation, और document-store migrations के लिए suitable। यह INSERT rows या query result sets को JSON में convert नहीं करता। «SQL to JSON» में search interest roughly आधे-आधे उन दो needs के बीच split होती है; यदि आप row-to-object conversion expect करके पहुंचे हैं, तो आपको एक अलग tool चाहिए। Schema-conversion path developer-facing case है: आपके पास एक table definition है और आप अपने shape का एक structured description चाहते हैं जिसे कोई दूसरा tool consume कर सके।

SQL का एक Short History

SQL को IBM के San Jose Research Laboratory में early 1970s में Donald D. Chamberlin और Raymond F. Boyce ने design किया था। Original नाम SEQUEL था: Structured English Query Language, IBM के experimental relational database System R के लिए higher-level interface के रूप में conceived। Relational model खुद 1970 में Edgar F. Codd ने publish किया था; Chamberlin और Boyce का contribution एक ऐसा syntax था जिसे ordinary analysts read कर सकें, Codd के algebraic symbols की बजाय natural English clauses (SELECT … FROM … WHERE …) पर modelled। Boyce (जो Boyce-Codd Normal Form को भी अपना नाम देंगे) 1974 में 26 साल की उम्र में die हुए, उस language के commercial release देखने से पहले जो उन्होंने co-invent की थी। 1975 में नाम SQL में बदल दिया गया Hawker Siddeley के SEQUEL trademark के साथ trademark conflict के कारण, हालांकि original «sequel» pronunciation United States में international «ess-cue-ell» के साथ-साथ persist करती है।

ANSI ने SQL को 1986 में standardise किया (SQL-86), ISO ने 1987 में ISO/IEC 9075 के रूप में essentially identical version ratify की, और standard तब से हर तीन से पांच साल में revised होता रहा है: SQL-92 (अभी भी most tutorials का assumed baseline), SQL:1999 (recursive queries, triggers), SQL:2003 (XML type, MERGE), SQL:2011 (temporal tables), SQL:2016 (JSON support), और most recently SQL:2023 (multi-dimensional arrays, property graph queries)। Competing technologies की waves के बावजूद (1990s में object databases, late 2000s में NoSQL, 2010s में data lakes) SQL पचास से अधिक वर्षों से structured data के लिए dominant query language के रूप में persist करता है। 2024 तक, अधिकांश NoSQL platforms ने भी SQL या SQL-like layers reintroduce कर दिए हैं (Cassandra का CQL, MongoDB का $sql aggregation stage, DynamoDB का PartiQL, Spark SQL, Trino, DuckDB, BigQuery, Snowflake), Mike Stonebraker की उस prediction को confirm करते हुए कि language किसी भी single storage engine को outlive करेगी।

JSON एक Paragraph में

JSON (JavaScript Object Notation) Douglas Crockford ने 2001 में specify किया था, JavaScript object literal syntax के एक subset से derived, और 2013 में ECMA-404 और 2017 में IETF RFC 8259 के रूप में standardised। इसमें केवल six value types हैं (string, number, boolean, null, array, object) और dates, decimals, binary, या schemas का कोई native concept नहीं है। JSON Schema (एक separate specification, currently draft 2020-12 पर) structural और type validation को ऊपर से layer करता है। इस converter के लिए JSON Schema का value: यह एक portable, schema-agnostic format है जिसे almost हर modern code-generator और validation library समझती है।

Mechanical Conversion

एक 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
);

Map होता है:

{
  "$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: input को tokenise करें, CREATE TABLE और table name locate करें, parenthesised column list find करें, top-level commas पर column definitions split करें (DECIMAL(10,2) या CHECK (x > 0) जैसी चीज़ों के लिए nested parentheses को respect करते हुए), हर column को name + type + modifiers में parse करें, और SQL type को closest JSON Schema type पर map करें। NOT NULL required array में membership बन जाता है। DEFAULT एक default value बन जाता है। PRIMARY KEY usually एक annotation या required में membership बन जाता है। CHECK, FOREIGN KEY, UNIQUE और indices typically text annotations बन जाते हैं क्योंकि JSON Schema का कोई direct equivalent नहीं है।

Dialect Problem

SQL famously dialects की एक family है, single language नहीं। Even basic identifier quoting भी differ करती है:

Type names भी diverge करते हैं। MySQL में INT(11) एक display-width hint है जिसे PostgreSQL reject करता है। PostgreSQL में SERIAL, INT NOT NULL AUTO_INCREMENT PRIMARY KEY के लिए shorthand है; IDENTITY SQL Server में same role fill करता है; SQLite AUTOINCREMENT use करता है। MySQL में BOOLEAN under the hood TINYINT(1) है। Geographic types (GEOMETRY, POINT), JSON column types (JSON, JSONB), array types (PostgreSQL का INTEGER[]) और full-text vector types (VECTOR(1536) in pgvector) का JSON Schema equivalent नहीं है और opaque string annotations के रूप में end up होते हैं। BLOB और BYTEA binary data का कोई native JSON representation नहीं है; standard practice contentEncoding hint के साथ base64-stringification है।

SQL Types vs JSON Types, Impedance Mismatch

SQL का एक rich type system है; JSON में six value types हैं और कोई schema नहीं है। जानने लायक:

इसे कब Use करें

Modern Alternatives

अधिक Questions

यदि मेरे CREATE TABLE में FOREIGN KEY constraints हों तो क्या होगा?

JSON Schema का कोई native foreign-key concept नहीं है। Cleanest representation एक custom annotation है (जैसे, एक non-standard x-foreign-key property) जो referenced table और column note करती है। यह converter relationship को output में text note के रूप में preserve करता है; यदि आपको fully-formal reference modeling चाहिए, तो JSON Schema का $ref + एक separate definitions block closest fit है, लेकिन many-to-many cases के लिए यह awkward है। Richer relational modeling के लिए DBML या Atlas HCL consider करें।

Output में CHECK constraints क्यों नहीं हैं?

JSON Schema कई simple CHECK constraints express कर सकता है, CHECK (age >= 0) {"minimum": 0} बन जाता है, CHECK (status IN ('a','b')) {"enum": ["a","b"]} बन जाता है: लेकिन CHECK clauses में arbitrary SQL expressions (function calls, joins, subqueries) का JSON Schema equivalent नहीं है। Converter simple cases recognise करता है और complex constraints को silently drop करने की बजाय text annotations के रूप में preserve करता है।

क्या मैं INSERT rows को JSON में convert कर सकता हूं?

इस tool से नहीं, यह only schema-level conversion (CREATE TABLE) handle करता है। Row-level conversion के लिए, सही approach usually database-native है: PostgreSQL का SELECT row_to_json(t) FROM tbl t, MySQL का JSON_OBJECT(), या CSV में export करके CSV-to-JSON tool use करना। mysqldump --xml को XML-to-JSON converter के माध्यम से pipe करना एक और well-trodden path है।

JSON में BIGINT problem क्यों है?

JavaScript का JSON.parse IEEE 754 doubles use करता है, जो केवल 2^53 = 9,007,199,254,740,992 तक integers exactly represent कर सकता है। ऊपर के numbers precision lose करते हैं। SQL BIGINT 2^63 ≈ 9.2 quintillion तक जाता है, safe JSON integer range से well beyond। JSON के माध्यम से BIGINT safely transport करने का cross-platform convention यह है कि इसे string के रूप में serialise करें और destination पर BigInt से parse करें; कई APIs (Twitter / X के tweet IDs, Stripe IDs, PostgreSQL का bigserial) exactly यही करते हैं।

क्या कुछ server पर भेजा जाता है?

नहीं। Parser आपके browser में run होता है; JSON output locally build होता है। Pasted SQL आपके device से कभी नहीं जाता, जो matters करता है यदि आपके CREATE TABLE statements proprietary column names, internal table conventions या ऐसे अन्य details contain करते हैं जो आप logged नहीं होने देना चाहते। Page एक बार load होने पर offline काम करता है।

संबंधित टूल

JSON फ़ॉर्मेटर

JSON को तुरंत फ़ॉर्मेट, मिनिफ़ाई और सत्यापित करें।

SQL फ़ॉर्मेटर

SQL क्वेरियाँ फ़ॉर्मेट और सुंदर करें।

XML फ़ॉर्मेटर

XML दस्तावेज़ों को फ़ॉर्मेट और सत्यापित करें।