ทำไมเราถึงใช้ CSV ต่อไป? [ปิด]

ทำไมเราถึงใช้ CSV ต่อไป?

เมื่อเร็ว ๆ นี้ฉันได้เปลี่ยนไปใช้โดเมนด้านสุขภาพและแม้จะมีงานที่ยอดเยี่ยมในมาตรฐานการถ่ายโอนข้อมูลการถ่ายโอนข้อมูลทั้งหมดอยู่ในรูปแบบCSVทั้งสำหรับการรายงานไปยังองค์กรภายนอกและสำหรับการย้ายข้อมูลเมื่อใช้ระบบใหม่

น่าเสียดายที่การใช้ CSV เป็นสาเหตุของการเกิดข้อผิดพลาดซ้ำ ๆ กันอย่างไม่มีที่สิ้นสุดโดยไม่มีเวลานักพัฒนาเท่ากัน (การหลบหนีไม่ดีการจัดการช่องว่างเป็นโมฆะ ฯลฯ )

ฉันรู้ว่าเราสามารถทำได้ดีกว่าและสิ่งใดระหว่าง JSON และ XML (ขึ้นอยู่กับตัวอย่าง) จะดี (ส่วนใหญ่เวลานี้เป็นข้อมูลไปจาก MS SQLserver 2005 หนึ่งไปยังอีก!)

ฉันรู้สึกราวกับว่าทุกครั้งที่ฉันเห็นสิ่งนี้เกิดขึ้น

แล้วทำไมเราถึงต้องลำกันต่อไปเรื่อย ๆ ? เมื่อไหร่เราจะหยุด

ในกรณีของคุณดูเหมือนว่า CSV ไม่เหมาะสมเนื่องจากไม่มีข้อมูลจำเพาะยาก

สำหรับข้อมูลที่ไม่สำคัญมันไม่ใช่ตัวเลือกที่ถูกต้อง

ทำไม / CSV ถึงเป็นตัวเลือกที่ดี? อาจจะมีหลายกรณีที่จะกล่าวถึงประโยชน์ของความเรียบง่ายสำหรับข้อมูลที่ชัดเจน ตราบใดที่ข้อมูลนั้นถูกฆ่าเชื้อ / หนีออกมาอย่างถูกต้องก็จะไม่มีปัญหา โดยทั่วไปแล้วแม้ว่าทุกกรณีเหล่านี้จะง่าย / ไม่สำคัญ แน่นอนว่าตัวคั่นมาตรฐานที่ปรากฏในเนื้อหามักจะเจ็บปวดเมื่อจัดการกับ CSV

แต่ถ้าคุณทำบางสิ่งที่เกี่ยวข้องมากกว่าการให้ไคลเอ็นต์ที่ไม่ใช่ด้านเทคนิคส่งข้อมูลจากแผ่นงาน Excel หรือกรณีการใช้งานที่คล้ายคลึงกันอื่น ๆ CSV อาจไม่เพียงพอสำหรับการใช้งานที่จริงจัง

XML นั้นเหมาะสมกว่า (ใช่มากกว่า JSON) เนื่องจากคุณสามารถทำรายละเอียดสคีมามาตรฐานแบบละเอียดได้ (ไม่ต้องพูดถึงว่ารายละเอียด / schemas เพลิดเพลินกับความยืดหยุ่นของรูปแบบการใช้งานที่หลากหลาย XSD, DTD และ Relax NG)

สำหรับระบบลูปปิดโดยเฉพาะอย่างยิ่งที่มีความกังวลเกี่ยวกับแบนด์วิดท์ JSON สามารถเหมาะสมกว่า XML แต่การขาดภาษาสคีมาข้อกำหนดมักจะกีดกันจากแอพพลิเคชั่นระดับองค์กร

ขอให้ฉันทิ้งคะแนนสองสามอันไปกับ CSV:

• CSV นั้นง่าย (r กว่าทางเลือกอื่น ๆ ที่แนะนำใน OP) เพื่อนำไปใช้และแยกวิเคราะห์
• CSV เข้าใจได้โดยซอฟต์แวร์เกือบทุกชิ้นในโลก (ในอดีตและปัจจุบัน)
• CSV บังคับให้สคีมาค่อนข้างเรียบง่าย (มีรายการฟิลด์เดียว)
• CSV สามารถอ่านได้ง่ายกว่า XML, JSON หรือ (UGH!) HL7 (V2.x, pre-xml)

เข้ากันได้ย้อนหลัง หากบริการเว็บองค์กรภายนอกของคุณจัดการ CSV และเครื่องมือที่มีอยู่ทั้งหมดของคุณจัดการกับ CSV ก็ไม่มีฝ่ายใดมีแรงจูงใจที่จะย้ายไปที่บริการใหม่ เหตุใดองค์กรภายนอกของคุณจึงเริ่มสนับสนุนรูปแบบที่แตกต่างกัน ไม่มีใครทำงานด้วยสามารถใช้มันได้! ทำไมคุณถึงเริ่มสร้างรูปแบบที่แตกต่างกัน? ไม่มีองค์กรที่คุณทำงานด้วยยอมรับเลย!

จริงปัญหาที่ผมเห็นนี่คือเหตุผลที่มีการพัฒนาของคุณกลิ้งรหัส CSV ของตัวเองทุกครั้ง? หากพวกเขาใช้ห้องสมุด CSV ที่มั่นคงและมั่นคงพวกเขาจะไม่มีปัญหาที่คุณอธิบาย ปัญหาเกิดจากนักพัฒนานำเสนอโซลูชันของตนเองแทนที่จะใช้ไลบรารีและฉันก็ไม่เห็นว่าการย้ายไปที่ JSON หรือ XML นั้นช่วยแก้ไขปัญหาได้อย่างไร คุณยังมีคนที่พยายามจะปลุกพวกเขาใหม่แทนที่จะใช้ห้องสมุด

CSV เป็นบิตเร็วขึ้น , มีขนาดเล็กกว่ามากง่ายต่อการจับ (แม้ใน Excel) และการใช้งานที่มีอยู่จำนวนมากเข้าใจมันเป็นใช้กันอย่างแพร่หลายมาตรฐาน

มันยังคงเป็นตัวเลือกแรกในหลาย ๆ สถานการณ์

ส่วนตัวแล้วฉันยังชอบรูปแบบนั้นอยู่มาก แต่ฉันใช้ JSON ด้วย แต่สำหรับแอปพลิเคชันอื่น ๆ เช่นเว็บ UI

สิ่งแรกและสำคัญที่สุดเพราะถึงแม้ว่าการบริโภคข้อมูล CSV อาจเป็นเพียงเล็กน้อย (เล็กน้อย) แต่การสร้างเป็นเรื่องง่ายมาก

ฉันยังชี้ให้เห็นว่าทั้ง JSON และ XML นั้นง่ายกว่าที่จะทำให้ถูกต้อง (สำหรับผู้ผลิตหรือผู้บริโภค) ในความเป็นจริงแล้วแทบจะไม่ต้องดูเลยรู้ว่าผู้คนจำนวนมากพยายามใช้ regexes เพื่อแยกวิเคราะห์ข้อมูล XML แม้ว่าจะมีคำถามที่ไม่สามารถทำได้และจะไม่ทำงาน

ปัญหาส่วนใหญ่ที่สามารถ (และทำ) เกิดขึ้นกับ CSV สามารถ (และทำได้) เกิดขึ้นกับทั้ง JSON และ XML โดยเฉพาะอย่างยิ่ง XML จะเพิ่มปัญหาที่อาจเกิดขึ้นของตัวเองอีกมากมาย ไลบรารีเพื่อวิเคราะห์ข้อมูล XML โดยทั่วไปจะมีขนาดใหญ่ขึ้นช้าลงและใช้งานได้ยากกว่าไลบรารีที่คล้ายกันสำหรับข้อมูล CSV

ครั้งแรกฉันยอมรับว่ามีปัญหาจริงบางอย่างกับรูปแบบ:

• มันพิมพ์อย่างเคร่งครัด
  • ไม่มีความแตกต่างระหว่างค่าข้อความและตัวเลข Excel จะเดาผิดและไขรหัสไปรษณีย์และหมายเลขบัตรเครดิตของคุณ
  • ไม่มีวิธีมาตรฐานในการแสดงข้อมูลไบนารี
  • ไม่มีวิธีมาตรฐานในการแยกแยะระหว่างNULLและ''ซึ่งเป็นปัญหาเมื่อนำเข้าไฟล์ CSV ไปยังฐานข้อมูล SQL
• การสนับสนุนไม่ดีสำหรับ "อักขระพิเศษ"
  • การไม่มีการอ้างอิงอักขระตัวเลขเช่น (XML &#xNNNN;หรือ JSON \uNNNN) หมายความว่าไม่มีวิธีมาตรฐานในการแสดงอักขระควบคุมหรืออักขระที่ไม่ใช่ ASCII
  • การใช้งานหลายอย่างไม่เหมาะสมใช้ตัวแบ่งบรรทัดภายในเขตข้อมูล
• การขาดมาตรฐาน มีRFC 4180แต่มันไม่ได้เป็นสากล

ในทางกลับกัน:

• ทางเลือกนั้นแย่กว่า JSON และ XML ได้รับการออกแบบรอบ ๆ ต้นไม้มีความเหมาะสมสำหรับข้อมูลบนโต๊ะโดยเฉพาะในแง่ของ ...
• แน่น! ใน XML คุณต้องมีแท็กเริ่มต้นและแท็กสิ้นสุดสำหรับแต่ละคอลัมน์ในแต่ละแถว ใน CSV คุณเขียนส่วนหัวคอลัมน์หนึ่งครั้งเท่านั้น
• CSV สร้างได้ง่ายมาก
• ผู้ที่ไม่ใช่โปรแกรมเมอร์สามารถเปิดไฟล์ CSV ใน Excel

เนื่องจากนักวิเคราะห์จำนวนมากใช้ Excel (สำหรับตารางเดือยและอื่น ๆ ) และมันเป็นเรื่องง่ายมากที่จะแสดงผล CSV มากกว่ารูปแบบ Excel ดั้งเดิม

เชิงอรรถ: จากจำนวนปัญหาที่ฉันพบกับ Excel ในการจัดการไฟล์ CSV เช่นการลบเลขศูนย์นำหน้าและการสูญเสียความแม่นยำนี่อาจเป็นความรู้สึกผิด ๆ

หากมีสิ่งผิดปกติเกิดขึ้นกับ CSV แสดงว่า CSV ปรากฏง่ายจนนักพัฒนาจำนวนมากพยายามประดิษฐ์ parsers / ผู้เขียนของตัวเองและต่อมาตำหนิ CSV ที่จัดการไม่ถูกต้อง ด้วยตัวแยกวิเคราะห์ CSV ที่ดี (อันที่ดีมาก ๆ ออกไป) จะไม่มีปัญหาเลย

CSV บางตัวที่กล่าวถึงไม่ดีสำหรับข้อมูลที่ไม่สำคัญ แต่ฉันไม่เห็นด้วย XML อนุญาตข้อมูลที่ไม่สำคัญเนื่องจากชุดข้อมูลที่แตกต่างกันสามารถใส่ในแท็ก "คอนเทนเนอร์" ที่แตกต่างกัน ด้วย CSV คุณสามารถใส่ข้อมูลที่แตกต่างในไฟล์ต่าง ๆ เพื่อให้ได้ผลเหมือนกัน

นอกจากนี้ในความคิดของฉันการใช้ XML สำหรับการถ่ายโอนข้อมูลโดยพื้นฐานนั้นขัดแย้งกับวัตถุประสงค์ของ XML - การถ่ายโอนข้อมูลมักจะแสดงถึงสัญญาที่มีเสถียรภาพระหว่างผู้ให้บริการและผู้บริโภคในขณะที่ XML นั้นหมายถึงการนำข้อมูลที่ขยายได้

ฉันเดาว่า CSV นั้นดีเมื่อคุณมีข้อมูลตัวอักษรแบบธรรมดาโดยมีเพียงเครื่องหมายจุลภาคและเครื่องหมายอัฒภาค / ท้ายทั้งคู่

ข้อมูลโครงสร้างแบบต้นไม้หรือข้อมูลแบบรวมสามารถใช้กับ CSV ได้ยาก

CSV เป็นเพียงอาร์เรย์ข้อความธรรมดา 2 มิติเช่นเดียวกับใน Excel ไม่มีอะไรมาก ...

มันเป็นเรื่องของเมนเฟรมและเก่งจริง ๆ ที่นี่

เมนเฟรมหลักเนื่องจากระบบเก่าเหล่านั้นหาวิธีการสื่อสารโดยใช้ CSV ดังนั้นแอพขนาดใหญ่ที่ถ่ายโอนข้อมูลสามารถอ่านและเขียนได้และไม่มีเหตุผลที่จะเปลี่ยนแปลงในขณะนี้

Excel เพราะสามารถเปิด CSV ได้โดยตรง ในความเป็นจริงมันต้องใช้เวลามากกว่านามสกุล. csv เมื่อคุณติดตั้ง ผู้ใช้เพียงคลิกไอคอน excel ที่ดูตลกเล็กน้อยและมันเปิดขึ้นและสร้างกริดที่ดี

ตอนนี้ Excel รุ่นใหม่มีความสามารถในการอ่านพูด XML โดยตรง แต่ในการทำเช่นนั้นผู้ใช้ต้องเข้าใจอีกนิดว่า "ดับเบิลคลิกที่ภาพนั้น" และการคลิกสองครั้งที่รูปภาพที่ถูกต้องอาจมากเกินไปที่จะถามในบางอุตสาหกรรม . .

ฉันเห็นคำตอบทางเทคนิคมากมาย แต่ฉันคิดว่าเหตุผลที่ผู้คนใช้ CSV เป็นเหตุผลเดียวกันกับที่ผู้คนใช้เทคนิค / เทคโนโลยีอื่น ๆ มากมายเพราะเป็นสิ่งที่พวกเขาคุ้นเคยมากที่สุด

ทำไมฉันถึงใช้มัน?

1. ลูกค้าต้องการมัน
2. มันเร็วกว่า xml ผ่านเครือข่าย (โหลดเครือข่ายขนาดเล็ก)
3. ไม่จำเป็นต้องมีความซับซ้อนมากขึ้นในการรับข้อมูล
4. ข้ามแพลตฟอร์ม
5. มนุษย์อ่านได้
6. ง่ายต่อการใช้ผู้อ่านและนักเขียนสำหรับมัน

ฯลฯ