आँकड़ों और विज्ञापन के लिए कुकीज़
हम आँकड़ों और विज्ञापन के लिए कुकीज़ इस्तेमाल करते हैं, दोनों Google को जाती हैं। मना करने से आपको दिखने वाली किसी चीज़ में कोई फ़र्क़ नहीं पड़ता।निजता पेज पढ़ें
यहाँ आप JSON को SQL में बदलते हैं, मुफ़्त और बिना खाते के: फ़ाइल ऊपर छोड़िए और कुछ ही सेकंड में नतीजा डाउनलोड के लिए तैयार मिलेगा। कन्वर्ज़न आपके अपने ब्राउज़र के भीतर होता है, इसलिए फ़ाइल कभी अपलोड नहीं होती। यह Windows, macOS और Linux पर वैसे ही चलता है जैसे iPhone और Android पर, और कनेक्शन काट देने पर भी चलता रहता है।
एक बार में 100 फ़ाइलें। फ़ॉर्मेट अलग-अलग हों तो भी चलेगा।
ये एक के बाद एक बदलती हैं और साथ में एक ZIP बनकर उतरती हैं।
JSON से SQL
नतीजा सिर्फ़ INSERT INTO ... VALUES की पंक्तियाँ हैं और कुछ नहीं। JSON बताता है कि कोई मान संख्या है, पर यह नहीं बताता कि कॉलम पूर्णांक है या दशमलव, वह ख़ाली रह सकता है या नहीं, या कौन-सी कुंजी प्राइमरी है।
इसलिए टेबल पहले से मौजूद होनी चाहिए। नतीजे में पहले स्टेटमेंट से कॉलम की सूची पढ़ लीजिए, उसी के हिसाब से टेबल बना लीजिए, फिर फ़ाइल चलाइए — यह दो मिनट का काम है और स्कीमा का फ़ैसला आपके हाथ में रखता है।
JSON दस्तावेज़ अपना कोई नाम नहीं रखता, इसलिए अपलोड की गई फ़ाइल ही एक देती है: orders.json से INSERT INTO orders बनता है। जो अक्षर SQL पहचानकर्ता में मान्य नहीं, वे अंडरस्कोर बन जाते हैं, और शुरुआत में अंक हो तो उसके आगे कुछ जोड़ दिया जाता है।
इसलिए बदलाव से पहले फ़ाइल का नाम बदल लेना सबसे सस्ता तरीक़ा है — बाद में हर स्टेटमेंट में खोज-बदल करना कहीं ज़्यादा मेहनत माँगता है।
रिलेशनल टेबल सपाट होती है, JSON नहीं — इसलिए customer के भीतर city जैसा नेस्टेड मान customer_city नाम का कॉलम बनता है। रास्ता बचा रहता है, बस बिंदी की जगह अंडरस्कोर आता है, क्योंकि पहचानकर्ता में बिंदी मान्य नहीं है।
एक स्तर की नेस्टिंग पर टेबल पढ़ने लायक़ रहती है। दो-तीन स्तर के बाद कॉलम की सूची यह बताने लगती है कि ढाँचे को असल में कई टेबल चाहिए, एक चौड़ी टेबल नहीं।
तीन टैग वाला रिकॉर्ड tags_0, tags_1 और tags_2 बनाता है। हर मान बच जाता है, पर अगला रिकॉर्ड जिसमें पाँच टैग हों वह टेबल को दो और कॉलम से चौड़ा कर देता है — और «दूसरे टैग» पर कोई समझदार क्वेरी नहीं बनती।
इसका सामान्य जवाब एक अलग टेबल है, हर टैग की अपनी पंक्ति के साथ। JSON से वहाँ तक पहुँचना दो बार बदलाव या इस चौड़ी टेबल को स्टेजिंग मानकर बाद में सामान्य बनाना माँगता है।
एक ही फ़ाइल के JSON रिकॉर्ड ज़रूरी नहीं कि एक जैसे हों — किसी API में ख़ाली फ़ील्ड अक्सर छोड़ ही दी जाती है। यहाँ पूरी फ़ाइल की सभी कुंजियों का मेल जोड़कर एक साझा सूची बनाई जाती है, और जिस रिकॉर्ड में कोई कुंजी नहीं थी वहाँ NULL लिख दिया जाता है।
इसी वजह से पूरी फ़ाइल एक बैच की तरह चलाई जा सकती है — कॉलम की सूची हर स्टेटमेंट में एक जैसी है। सिर्फ़ कुछ रिकॉर्ड पर परखने से यह सूची अधूरी दिख सकती है; DDL हमेशा पूरी फ़ाइल के बदलाव से बनाइए।
बूलियन मान TRUE और FALSE की तरह लिखे जाते हैं, जो हर SQL डायलेक्ट में सीधे स्वीकार नहीं होता। पहचानकर्ता — टेबल और कॉलम के नाम — बिना किसी उद्धरण चिह्न के लिखे जाते हैं।
अपने इंजन के हिसाब से इन्हें ढालना एक सादा खोज-बदल है, पर चलाने से पहले यह जाँच लेना बेहतर है, क्योंकि कुछ डेटाबेस TRUE/FALSE की जगह 1/0 माँगते हैं।
यहाँ किसी SQL फ़ाइल को पढ़कर वापस JSON बनाने का कोई रास्ता नहीं — पूरी साइट पर SQL सिर्फ़ लिखा जा सकता है, पढ़ा नहीं। INSERT स्टेटमेंट से पीछे लौटने का कोई कन्वर्टर नहीं है।
इसलिए यह पेज सिर्फ़ उस दिशा के लिए है: आपके पास JSON है और आपको एक टेबल में डालने लायक़ पंक्तियाँ चाहिए, इससे उलटा नहीं।
स्टेटमेंट इसी टैब में जावास्क्रिप्ट से बनते हैं। कुछ अपलोड नहीं होता, कोई खाता या कतार नहीं है, और मुफ़्त स्तर 100 MB तक स्वीकार करता है — असली सीमा मेमोरी की है, क्योंकि पूरा दस्तावेज़ पहले पढ़ा जाता है, तभी कुछ लिखा जाता है।
जो डेटा किसी डेटाबेस में डाला जाना है, वह अक्सर वही डेटा होता है जिसके लिए संस्था सबसे ज़्यादा जवाबदेह है — ग्राहक, ऑर्डर, खाते। इसे किसी तीसरे पक्ष के कन्वर्टर से गुज़ारना यहाँ ज़रूरी ही नहीं है।
| JSON | SQL | |
|---|---|---|
| पूरा नाम | JavaScript Object Notation | SQL INSERT कमांड |
| फ़ाइल एक्सटेंशन | .json | .sql |
| मीडिया टाइप | application/json | application/sql |
| पहली बार प्रकाशित | 2001 | 1986 |
| विनिर्देश | RFC 8259 | ISO/IEC 9075 |
| लाइसेंस | खुला मानक | खुला मानक |
| आज की स्थिति | मौजूदा | मौजूदा |
| ब्राउज़र में खुलता है | हर ब्राउज़र | कोई ब्राउज़र नहीं |
| इसकी जगह विचारणीय | XML, YAML, NDJSON | CSV, Parquet |
SQL को कोई भी ब्राउज़र नहीं पढ़ता। इस लिहाज़ से दोनों में यही कम जगह चलने वाला है। भेजने से पहले देख लीजिए कि पाने वाला इसे लेता भी है या नहीं।
दोनों तरफ़ के प्रोग्राम अलग हैं: JSON फ़ाइल Visual Studio Code, jq और Postman में खुलती है और SQL फ़ाइल PostgreSQL, MySQL और DBeaver में — यानी नतीजा जिसके पास जाएगा, उसे दूसरी सूची में से कोई प्रोग्राम चाहिए होगा।
JSON 2001 में आया। यह RFC 8259 में तय किया गया है, और अगर फ़ाइल को उस औज़ार से ज़्यादा जीना है जिसने उसे लिखा, तो यह बात क़ीमती है।
SQL 1986 से चला आ रहा है, और ISO/IEC 9075 में तय किया गया है। PostgreSQL, MySQL और DBeaver इस फ़ॉर्मेट को पढ़ लेते है।
SQL 1986 में आया और JSON 2001 में। किसी को सौंपने के लिए आम तौर पर पुराना वाला ज़्यादा सुरक्षित रहता है; नया वाला वही काम कम बाइट में कर देता है।
नहीं। यह कन्वर्ज़न पूरी तरह आपके ब्राउज़र में होता है, इसलिए फ़ाइल आपके डिवाइस से बाहर नहीं जाती। आप ख़ुद जाँच सकते हैं: डेवलपर टूल्स का नेटवर्क टैब खोलिए और कुछ बदल कर देखिए। आपको पेज ख़ुद दिखेगा और आँकड़ों तथा विज्ञापन के वे अनुरोध दिखेंगे जिनसे इस सेवा का ख़र्च निकलता है — और एक भी ऐसा अनुरोध नहीं जो आपकी फ़ाइल साथ ले जा रहा हो।
हाँ। न खाता, न वॉटरमार्क, और न कोई रोज़ का कोटा जो ख़त्म हो: यह आपकी अपनी मशीन पर चलता है, इसलिए आप जितनी बार चाहें लौट सकते हैं। ब्राउज़र 100 MB तक की फ़ाइलें सँभालता है, एक बार में 100।
JSON और SQL सामग्री का वर्णन बुनियादी तौर पर अलग-अलग तरीक़ों से करते हैं। इसलिए यह कन्वर्ज़न नक़ल नहीं, पुनर्निर्माण है: ईमानदार, पर बाइट-दर-बाइट एक जैसा नहीं। एक के अंदर एक बैठी वस्तुएँ चपटी होकर कॉलम बन जाती हैं। गहराई तक बैठा डेटा अपना आकार खो देता है।
SQL को कोई भी ब्राउज़र नहीं पढ़ता। इस लिहाज़ से दोनों में यही कम जगह चलने वाला है। भेजने से पहले देख लीजिए कि पाने वाला इसे लेता भी है या नहीं।