Friends CSV में export करने नहीं देते

मूल लेख ↗ Hacker News चर्चा ↗

CSV की सार्वभौमिक “export” format की स्थिति पर engineers सवाल उठाते हैं, क्योंकि यह underspecified, fragile, और बड़े-scale data pipelines के लिए inefficient है; वे Parquet, SQLite, या line-delimited JSON जैसे formats की ओर संकेत करते हैं। दूसरी ओर, आलोचक कहते हैं कि CSV की human readability और लगभग सार्वभौमिक support—खासकर Excel और समान tools के जरिए—इसे business users और cross-organization data exchange के लिए अनिवार्य बनाती है, भले ही इसमें locales, encodings, और type ambiguity जैसी quirks हों। उभरती सहमति यह है कि जहाँ humans और spreadsheets शामिल हों वहाँ CSV देना जारी रखें, लेकिन systems के बीच बड़े या critical datasets भेजने के लिए अधिक structured, schema-aware formats को प्राथमिकता दें।

CSV क्यों अब भी dominant है

  • सार्वभौमिक रूप से समर्थित: लगभग हर business tool, database, और language CSV को import/export कर सकती है, अक्सर बिना किसी extra libraries के।
  • गैर-तकनीकी उपयोगकर्ताओं के लिए काम आता है: लोग “export/import CSV” और “open in Excel/Sheets” जानते हैं; कई workflows, FOIA responses, और legacy systems इसके आसपास बने हैं।
  • छोटे या मध्यम files के लिए देखना और हाथ से edit करना आसान है। integrations और “one broken file” incidents debug करने में यह critical है।
  • मध्यम data sizes (MBs से low GBs) के लिए performance आम तौर पर पर्याप्त अच्छी होती है, खासकर जब zipped हो।

CSV की व्यावहारिक समस्याएँ

  • अस्पष्ट “family” of formats: अलग-अलग delimiters (,, ;, \t, |), quoting rules, header की मौजूदगी, encodings (UTF‑8 vs legacy), decimal separators, date formats, और null representations।
  • वास्तविक दुनिया की files अक्सर RFC 4180 का उल्लंघन करती हैं: inconsistent quoting, गलत escaping, comments, misaligned rows, fields में nested CSV। “सभी CSVs” के लिए एक single robust parser व्यावहारिक रूप से असंभव है।
  • locale और Excel की समस्याएँ: Excel locale के आधार पर separator बदलता है, types का अनुमान लगाता है, IDs को numbers/dates/scientific notation में बदल देता है, leading zeros हटा देता है, और save करने पर चुपचाप data corrupt कर सकता है। LibreOffice को अक्सर अधिक sane बताया जाता है।
  • encoding और schema out-of-band होते हैं; consumers को types और formats का अनुमान लगाना पड़ता है, जिससे subtle bugs पैदा होते हैं।

“Human readable” पर बहस

  • Pro: Human readability को एक बड़ा virtue माना जाता है। आप बिना code के data inspect, diff, और surgically fix कर सकते हैं। CSV को durable और future-proof माना जाता है।
  • Con: Human readability ad-hoc, buggy producers (“बस commas से जोड़ दो”) को बढ़ावा देती है, जिससे interoperability और खराब होती है। कुछ लोग कहते हैं binary + अच्छे tools, text + misuse से बेहतर है।

Parquet और अन्य alternatives

  • Data pipelines के लिए Parquet की प्रशंसा की जाती है: columnar, typed, schema-aware, बड़े datasets और partial reads के लिए efficient; अच्छी तरह compress होता है (csv.gz के तुल्य)।
  • आलोचनाएँ: अधिक complex spec, कुछ languages/environments में spotty या painful library support, version quirks, Excel में सीधे उपयोग योग्य नहीं, और row-streaming use cases के लिए आदर्श नहीं।
  • अन्य सुझाए गए formats: SQLite files, Arrow, Avro, Protobuf/Cap’n Proto, JSON/NDJSON, TSV, schema के साथ XML, CSVY (CSV + YAML metadata), और समर्पित delimiter characters का उपयोग करने वाले “Unicode/ASCII separated values”。

CSV कब उपयुक्त है और कब नहीं

  • व्यापक रूप से सहमति:
    • बाहरी stakeholders और spreadsheets में ad-hoc analysis के लिए CSV (या XLSX) रखें।
    • उन internal, बड़े, या performance-sensitive pipelines के लिए Parquet/SQLite/Arrow/etc. पर विचार करें जहाँ आप दोनों ends नियंत्रित करते हैं।
  • मुख्य तनाव: CSV तकनीकी रूप से fragile है लेकिन सामाजिक रूप से entrenched है। बहुत से लोग इसे बड़े scale पर बदलना अव्यावहारिक मानते हैं; दूसरे तर्क देते हैं कि कम-से-कम इसे “serious” system-to-system integration के लिए default के रूप में इस्तेमाल करना बंद कर देना चाहिए।