CSV को SQL में बदलें

यह पहले कहना ज़रूरी है, क्योंकि इस रूपांतरण को खोजने वालों में से बहुतों को इसकी ज़रूरत नहीं। Postgres के पास COPY है, MySQL के पास LOAD DATA INFILE, SQLite के पास .import — और हर एक delimited फ़ाइल सीधे पढ़ता है और block में लिखता है। कुछ हज़ार पंक्तियों से ऊपर वह रास्ता आराम से जीतता है।

इस रूपांतरण को सही चुनाव बनाती है एक बाध्यता, पसंद नहीं। Bulk loader को फ़ाइल सर्वर की पहुँच में चाहिए, और अक्सर कोई अनुमति जो account के पास नहीं। अगर आपके पास सिर्फ़ एक query window है, तो statement ही इस्तेमाल में लाने लायक़ मुद्रा हैं।

आउटपुट सिर्फ़ INSERT स्टेटमेंट की फ़ाइल है, एक-एक पंक्ति के लिए, टेबल नाम रखते और header row से लिए कॉलम गिनाते हुए। इससे पहले कुछ नहीं। यह चूक नहीं, इनकार है — CSV न प्रकार रिकॉर्ड करता है, न लंबाई, न keys, इसलिए बनाई गई schema अनुमानों का समूह होगी।

ग़लत अनुमान की क़ीमत असमान है। ग़लत पंक्ति एक ग़लत record है और delete उसे ठीक कर देता है। नमूने की सबसे लंबी value से अनुमानित VARCHAR(50) दो साल तक पते काटता रहता है, बिना किसी के ध्यान में आए।

CSV का नाम, बिना एक्सटेंशन के, टेबल के रूप में इस्तेमाल होता है। रास्ते में इसे साफ़ किया जाता है — अक्षर, अंक और underscore के बाहर कुछ भी underscore बन जाता है, और अंक से शुरू होने वाले नाम के आगे एक underscore जुड़ जाता है।

यही साफ़-सफ़ाई header row से लिए कॉलम नाम पर भी लागू होती है, जो चौंकाने की ज़्यादा संभावना रखता है। `Order total (£)` जैसा header `Order_total____` बन जाता है और आपकी टेबल में किसी से मेल नहीं खाएगा। CSV में header को ठीक करना और फ़ाइल का नाम लक्ष्य टेबल जैसा रखना बेहतर है।

यही है वह जगह जहाँ CSV को स्प्रेडशीट से बदलने में फ़र्क़ पड़ता है, और यही सबसे ज़्यादा ग़लत होने वाली चीज़ है। स्प्रेडशीट सेल जानता है वह टेक्स्ट है या संख्या। CSV field सिर्फ़ अक्षर हैं, इसलिए parser अंदाज़ा लगाता है।

व्यावहारिक नतीजा है कि identifier कॉलम अपने quotes और padding दोनों खो देते हैं। 01234 का postcode `1234` बनकर बिना quote के लिखा जाता है। identifier कॉलम को quote करके या non-numeric prefix के साथ export कीजिए, या बनी फ़ाइल में जाँच लीजिए।

दो delimiter के बीच का ख़ाली space NULL keyword बन जाता है, ख़ाली स्ट्रिंग नहीं। यह किसी export में गैप की लगभग हमेशा सही पढ़ाई है, और यह वह पढ़ाई है जिसे NOT NULL constraint चुपचाप स्वीकार करने के बजाय ज़ोर से अस्वीकार करेगा।

जहाँ ख़ाली का असल मतलब खाली स्ट्रिंग था, फ़ाइल में यह फ़र्क़ कभी था ही नहीं और कोई कन्वर्टर इसे वापस नहीं ला सकता। अगर आपकी टेबल में एक कॉलम है जहाँ "" और NULL अलग मतलब रखते हैं, तो यह फ़र्क़ बदलने से पहले CSV में एनकोड कर लीजिए।

संख्याएँ और boolean बिना quote लिखी जाती हैं। टेक्स्ट single quote में लिपटता है, भीतर मौजूद apostrophe दोगुना होता है — तो O'Brien, 'O''Brien' बनता है। यह ANSI परंपरा है और हर बड़ा इंजन इसे एक जैसे पढ़ता है।

Backslash escaping जान-बूझकर नहीं है। यह एक MySQL extension है जिसका व्यवहार server setting पर निर्भर करता है, इसलिए एक फ़ाइल एक सर्वर पर सही चलती है और दूसरे पर डेटा बिगाड़ सकती है।

CSV में `true` या `false` पढ़ी value boolean के रूप में पढ़ी जाती है और bare literal TRUE या FALSE के रूप में लिखी जाती है। Postgres इसे सीधा स्वीकार करता है, MySQL इन शब्दों को 1 और 0 का alias मानता है।

SQL Server नहीं। इसका bit type 1 और 0 चाहता है, और TRUE वाला statement parse नहीं होता — यह आप चौथे सौवें statement पर देखेंगे अगर boolean कॉलम में ऊपर ख़ाली की एक लड़ी हो। अगर यही मंज़िल है, चलाने से पहले बदल लीजिए।

इस रूपांतरण में कुछ भी किसी तारीख़ की व्याख्या नहीं करता। `2024-03-11` लिखा field संख्या नहीं है, इसलिए यह स्ट्रिंग रहता है और quote करके लिखा जाता है, और `11/03/2024` लिखा field भी ऐसा ही करता है। यह लगता उससे बेहतर है — quote की ISO तारीख़ हर इंजन में सही insert होती है।

यही जगह है जहाँ अस्पष्टता बिना छुए यात्रा करती है। `11/03/2024` किसका इशारा है — यह फ़ाइल नहीं बताती। जिस CSV की तारीख़ शैली आप पक्का नहीं कर सकते, उसे एक text staging कॉलम में लोड करके साफ़ तौर पर बदलिए।

Statement अलग-अलग निकलते हैं, कोई BEGIN नहीं, कोई COMMIT नहीं, कोई multi-row VALUES batching नहीं। किसी दूर के सर्वर पर जैसा है वैसा चलाना पचास हज़ार round trip और उतने ही implicit commit है।

दो लाइनें दोनों समस्याएँ ठीक करती हैं — फ़ाइल को BEGIN और COMMIT में लपेट दीजिए। फ़ाइल भी उसमें मौजूद डेटा से बड़ी है, क्योंकि हर लाइन पर कॉलम सूची दोहराई जाती है।

फ़ाइल पढ़ना और statement लिखना दोनों सादा JavaScript है जो यहाँ चलता है, इसलिए कुछ अपलोड नहीं होता। इस जोड़ी पर यह ख़ासतौर पर मायने रखता है — डेटाबेस की ओर जाती CSV आम तौर पर ग्राहक रिकॉर्ड या transaction होती है।

सीमा है पूरी टेबल एक साथ मेमोरी में रखना, जो दसियों मेगाबाइट को आराम से समेट लेती है। उससे ऊपर जवाब bulk loader है, पहले सेक्शन से, और वह वैसे भी बेहतर जवाब है।