CSV เป็นทางเลือกที่ดีสำหรับ XML และ JSON หรือไม่ [ปิด]

เป็นCSVถือว่าเป็นตัวเลือกที่ดีกับXMLและJSONสำหรับการเขียนโปรแกรมภาษา?

ฉันมักจะใช้ XML และ JSON (หรือบางครั้งไฟล์ข้อความธรรมดา) เป็นที่เก็บไฟล์เรียบ อย่างไรก็ตามเมื่อเร็ว ๆ นี้ผมมาในการดำเนิน CSV ในPHP โดยทั่วไปฉันเคยเห็น CSV ใช้สำหรับอินพุตในไฟล์Excelแต่ฉันไม่เคยใช้กับการเขียนโปรแกรม มันจะดีกว่า XML หรือ JSON แต่อย่างใด

คำตอบคือมันขึ้นอยู่กับ

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

นอกจากนี้ยังเป็นจริงทั่วไปในอุตสาหกรรมบางประเภทเมื่อจัดการกับระบบเดิมและเวิร์กโฟลว์ ลองนำเข้า JSON ไปยัง MS Excel

ODI เพิ่งแสดงความคิดเห็นเกี่ยวกับ CSV โทร 2014 "ปีแห่ง CSV"

สำหรับการจัดรูปแบบ CSV ที่ "เหมาะสม" ให้พิจารณาใช้ประเภท mime ของ CSVในการตอบกลับ HTTP ของคุณ

ส่วนใหญ่ไม่แน่นอน

CSV เป็นรูปแบบตารางที่แมปได้ดีกับชุดข้อมูลหรือข้อมูลแบบตารางอื่น ๆ แต่ไม่ใช่ว่าข้อมูลทั้งหมดจะเป็นตาราง! ส่วนใหญ่โดยทั่วไปเราต้องการที่จะเป็นอันดับกราฟวัตถุ ซึ่งอาจเป็นเรื่องยากในกรณีต่อไปนี้:

• การอ้างอิงแบบวงกลม
• subgraphs ที่ใช้ร่วมกัน (เช่นสองวัตถุที่ทั้งสองมีวัตถุเดียวกันเป็นสมาชิก)
• วัตถุประเภทต่าง ๆ ที่จะต่อเนื่องกันในเอกสารเดียวกัน

เราต้องการที่จะสามารถลดความน่าเชื่อถือของวัตถุจากรูปแบบการจัดเก็บของเรา

XML

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

JSON

เป็นวิธีการเก็บต้นไม้วัตถุอย่างง่ายเป็นหลัก ไม่มีการสนับสนุนกราฟทั่วไป JSON มีแนวคิดของการไม่มีชนิดเกินพื้นฐานสตริง , จำนวนเต็ม , ลอย , บูล , nullและชนิดคอลเลกชันอาร์เรย์และวัตถุ

YAML

เข้าใจได้ง่ายที่สุดว่าเป็นส่วนเสริมของ JSON มีแนวคิดเกี่ยวกับนามแฝงที่อนุญาตให้สร้างกราฟวัตถุที่มีความซับซ้อนตามอำเภอใจ มีแนวคิดเกี่ยวกับข้อมูลเมตาเช่นแท็กที่สามารถใช้สำหรับการพิมพ์ที่เหมาะสม

CSV

ไม่มีอะไรเลยยกเว้นโต๊ะเดี่ยว ถ้าเราต้องการเก็บกราฟวัตถุเราจะต้องใช้สคีมาเช่น

#ID,Type,Field1,Field2,...,FieldN

1,String,foo
2,String,bar
3,Array<String>,1,2

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

ดังนั้นโดยทั่วไปสิ่งง่าย ๆ จะยากหรือเป็นไปไม่ได้เมื่อใช้ CSV เป็นรูปแบบการทำให้เป็นอนุกรมทั่วไป

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

ฉันต้องบอกว่ามันขึ้นอยู่กับสิ่งที่คุณพยายามจะทำ สำหรับปัญหาต่าง ๆ มันไม่สำคัญว่าคุณจะเลือกอะไรถ้าปัญหานั้นเล็กพอและตัวเลือกของคุณเหมาะสมกับระบบที่มีอยู่

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

หลายปีที่ผ่านมาฉันทำงานกับระบบฐานข้อมูลกราฟการวิจัยซึ่งขึ้นอยู่กับไฟล์ CSV ในรูปแบบต่างๆ ผู้นำเข้าไฟล์ CSV จะสร้างกราฟให้เราและมีการทำงานเป็นเวลาหลายปีในการดีบักและเพิ่มประสิทธิภาพโค้ด มันทั้งเร็วและยืดหยุ่นและเราใช้มันอย่างมีความสุขในการบูทโครงการวิจัยขนาดใหญ่ เมื่อ XML ปรากฏบนฉากเราเพิ่มผู้นำเข้า XML แต่ไม่จำเป็นต้องปรับปรุงในเรื่องของความเร็วหรือการแสดงความซับซ้อนและแน่นอนว่า XML นั้นไม่ได้ดีไปกว่าการแสดงโครงสร้างกราฟมากกว่า CSV JSON ดีกว่า XML (และ terer) มาก แต่คล้ายกันหลายประการดังนั้นฉันจึงคาดหวังผลลัพธ์ที่คล้ายกันเมื่อสร้างผู้นำเข้าใหม่ในระบบนั้น

ในช่วงเวลาหนึ่งเรามีลูกค้านำข้อมูลจำนวนมากในรูปแบบ "cobol" ไฟล์ที่มีบรรทัดที่มีความยาวของตัวแปรที่มีเครื่องหมายซึ่งระบุวิธีตีความไบต์ที่ตามมาในบรรทัดนั้น มันมาจากช่วงเวลาที่การจัดเก็บมีราคาแพงดังนั้นความกะทัดรัดเป็นข้อกำหนด เรานำเข้าข้อมูลนั้นโดยแปลงเป็นรูปแบบ CSV ได้ทันทีและป้อนลงในตัวนำเข้า CSV นั่นเป็นเรื่องง่ายที่จะทำและลดจำนวนการดีบักและบำรุงรักษาซึ่งเป็นสิ่งที่ดี หากเราต้องนำเข้าข้อมูลประเภทนั้นตลอดเวลาเราอาจสร้างมันไว้ในระบบโดยตรงเพื่อรับประสิทธิภาพและประสิทธิภาพที่เพิ่มขึ้น

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

เลขที่

CSV ไม่ใช่รูปแบบเดียวจริงๆ มีหลากหลายสไตล์สำหรับการหลีกเลี่ยงตัวคั่นและปัญหาการจัดรูปแบบอื่น ๆ ที่ไฟล์ CSV จำนวนมากในรุ่นธรรมดามีอยู่

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

ฉันจะขอแนะนำอย่างยิ่งกับมัน ฉันอาจจะออก CSV ในบางจุด (ถ้าผู้ใช้ร้องขอ) แต่มันเป็นแบบที่ไม่ดีสำหรับวัตถุประสงค์ในการจัดเก็บ / นำเข้า นี่คือสาเหตุส่วนใหญ่เนื่องจาก "CSV" นั้นไม่ชัดเจนมาก "C" หมายถึง "เครื่องหมายจุลภาค" หรือ "ตัวอักษร" คั่นหรือไม่? คุณปฏิบัติต่อสตริงข้อความที่มีอักขระ escape เช่น "ได้อย่างไรการใช้ CSV ที่ถูกสาปทุกครั้งจะใช้อักขระ escape อื่น ๆ แตกต่างกันซึ่งนำไปสู่ไฟล์ที่สามารถยกเว้น แต่ไม่นำเข้าเป็นต้น

Excel เป็นการสาธิตที่ดี: ในเวอร์ชันภาษาอังกฤษจะใช้ "," เป็นตัวคั่น ในเยอรมนีใช้ ";" ดังนั้นเวอร์ชันภาษาเยอรมันจึงฉายในไฟล์ CSV ภาษาอังกฤษและในทางกลับกัน ...

จุดแข็งหลักคือความสามารถในการอ่านของมนุษย์ซึ่งไม่ควรลดราคา แต่ฉันจะไม่พึ่งพามันเป็นรูปแบบการจัดเก็บข้อมูลมันเปราะเกินไปสำหรับวัตถุประสงค์นั้น หากคุณต้องส่งออกไฟล์สำหรับมนุษย์คุณอาจใช้ CSV แต่ถึงอย่างนั้นฉันก็จะลองใช้ห้องสมุดที่เขียนไปยังไฟล์ xlsx (พวกเขาสามารถใช้งานได้อย่างอิสระ)

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