วิธีการตัดสินใจระหว่างรูปแบบการจัดเก็บและกรณีตัวอย่างการใช้งานสำหรับบางรูปแบบ?


10

เรามีวิธีต่าง ๆ ในการจัดเก็บข้อมูลโปรแกรม (บันทึกไฟล์ในเกมฐานข้อมูลพนักงานการกำหนดค่าโปรแกรม ฯลฯ ):

  • ข้อความล้วน (คิด.iniและ.conf)
  • XML
  • ฐานข้อมูล (MySQL, SQLite ... )
  • .zip และที่คล้ายกันมีหลายไฟล์ (ที่มีรูปแบบที่แตกต่างกัน)
  • ไฟล์ไบนารี (คิดว่า.docเป็นต้นเช่นสร้างโดยเครื่องมือการทำให้เป็นอนุกรม)

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

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

message.txt (containing the message)
attachments (folder containing attachments)
  audio.wav
  picture.jpg

wrt binary พิจารณา Google Protocol Buffer ความสามารถในการดีซีเรียลไลซ์เซชันเป็นเลิศและคุณมีความเป็นไปได้ที่จะแยกมันออกมาและบันทึกใหม่เป็นข้อความที่จัดรูปแบบ (ในหลายภาษา C ++ / Java / Python)
Matthieu M.

คำตอบ:


6

ฉันใช้ดังต่อไปนี้:

ข้อความธรรมดา

สำหรับการกำหนดค่า - มักจะใช้ YAML หรือ. ini เลิกใช้แล้วสำหรับการใช้งานส่วนใหญ่ยกเว้นเมื่อไฟล์ข้อความเป็นผลลัพธ์ที่ต้องการ (เช่นพิมพ์เป็นข้อความบันทึกเป็นข้อความ ฯลฯ )

XML

สำหรับการกำหนดค่าและการขนส่งข้อมูล เช่นการส่งออกจัดรูปแบบผ่าน XSLT เป็นต้นเป็นไฟล์รูปแบบพกพา (เช่น SVG) เครื่องมือและตัวกรองที่ยอดเยี่ยม

ฐานข้อมูล

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

ไฟล์เดียวที่เก็บถาวร (เช่น. zip)

เหมาะสำหรับการจัดเก็บสตรีมไบนารีหลายรายการที่เกี่ยวข้องอย่างกระชับเช่นภาพ ROM สำหรับอีมูเลเตอร์ ดีที่สุดสำหรับสิ่งที่ไม่บ่อยหรือไม่จำเป็นต้องได้รับการอัปเดต มันเป็นรุ่นหนา, ช้าและยากที่จะจัดการ;

ไบนารี่

เฉพาะที่ฐานข้อมูลไม่พร้อมใช้งานสำหรับจัดเก็บข้อมูลแอป ง่ายที่สุดด้วยการทำให้เป็นอนุกรม (C ++) รูปแบบไบนารีที่ได้รับการปรับแต่งสูงจะมีประสิทธิภาพเหนือกว่าทุกอย่างอื่นทั้งความเร็วและขนาด


4

ไม่มีกระสุนเงิน จากประสบการณ์ของฉัน:

ข้อความธรรมดาเป็นสื่อกลางในการจัดเก็บเป็นหมายเลขอัตโนมัติ บางกรณีฉันจะพิจารณาว่ามันจะดีกว่าโดยไฟล์. config ที่ฉันมีสคีมาและความปลอดภัยของประเภท ดูเหมือนว่าความต้องการความปลอดภัยประเภทและการดึงข้อมูลมาเกือบตลอดเวลา ข้อความธรรมดาทำให้กระบวนการนี้เป็นฝันร้าย

XML : ประเภทความปลอดภัย, การตรวจสอบความถูกต้องของข้อมูล, ระดับเสียงต่ำและในบางกรณีฉันใช้งานเนื่องจาก. NET มีประสิทธิภาพในการรองรับการทำให้เป็นอันดับ XML ของวัตถุ

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

.zipเป็นรูปแบบการบีบอัดไม่แน่ใจว่าสิ่งนี้เหมาะสมกับการทนต่อ .. หรือไม่

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

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


3

ฉันใช้พวกเขาดังต่อไปนี้:

ข้อความธรรมดา

หากหมวดหมู่นั้นมีรูปแบบที่ซับซ้อนกว่าเล็กน้อยเช่น YAML หรือไฟล์คุณสมบัตินั่นเป็นตัวเลือกที่ดีที่สุดสำหรับทุกสิ่งที่คุณคาดหวังให้คนอ่านและแก้ไขด้วยมือ ข้อดีอีกอย่างคือความเรียบง่ายของการแก้ไขผ่านสคริปต์ขนาดเล็ก (เช่น sed)

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

XML

ฉันเห็นด้วยกับ @Ingo ที่นี่ - ซึ่งแตกต่างจาก XML ข้อความธรรมดายากที่จะดำเนินการผ่านการเขียนสคริปต์และฝันร้ายที่จะแก้ไขด้วยมือ IMO

อย่างไรก็ตามหากคุณมีข้อมูลที่มีโครงสร้างที่ซับซ้อนซึ่ง YAML ไม่สามารถถอดรหัสได้และยังต้องการให้มนุษย์อ่านและแก้ไขได้ XML อาจเป็นตัวเลือกที่ดีที่สุด

ฐานข้อมูลเชิงสัมพันธ์

ทางเลือกที่ยอดเยี่ยมสำหรับเมื่อคุณมีข้อมูลจำนวนมาก (ซึ่งจะทำให้ข้อความธรรมดาและ XML ยุ่งยาก) ซึ่งคุณอาจต้องการอนุญาตให้บุคคลที่สามแก้ไขด้วยตนเองผ่านคำสั่ง SQL และ GUI

ข้อดีอีกอย่างคือรหัสของคุณที่จัดการเนื้อหานั้นสามารถอ่านได้มาก @ Richard-Harrison ให้รายการข้อดีอื่น ๆ ไว้ในคำตอบที่ยอดเยี่ยมของเขา

ฐานข้อมูล NoSQL

ข้อดีอย่างหนึ่งของ RDBMS ก็คือความสามารถในการขยายผ่านการกระจายซึ่งอาจไม่เกี่ยวข้องกับคำถามของคุณ ข้อดีที่น่าจะเกี่ยวข้องมากกว่านั้นก็คือความเรียบง่ายของที่เก็บคีย์ - ค่าและความยืดหยุ่นของ schemalessness (นี่คือคำหรือไม่) เมื่อคุณพบว่าตัวเองขัดขืนกระบวนทัศน์เชิงสัมพันธ์: เพียงเก็บ blobs ไปยังฐานข้อมูลเข้าถึงพวกมันด้วยกุญแจและประมวลผลพวกมันผ่านโค้ดจากนั้นพิจารณาตัวเลือกนี้ ตัวเลือกบางอย่าง (เช่น CouchDB) เป็นแบบพกพามีรอยขนาดเล็กและยังสามารถปรับขนาดได้เพื่อเสนอทางเลือกที่ไม่สัมพันธ์กับ MySQL และ SQLite

ไบนารี่

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

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

หมายเหตุ: มีความเข้าใจผิดว่าไบนารีนั้นทึบแสงและทำให้ปลอดภัยยิ่งขึ้น หากไม่มีการป้องกันเพิ่มเติมจะไม่มี - หากมีคนต้องการแฮ็คซอฟต์แวร์ของคุณเพียงแค่จัดเก็บการกำหนดค่าของคุณหรืออะไรก็ตามที่อยู่ในไบนารีจะไม่หยุดพวกเขา

บีบอัดไฟล์เก่า

ไม่ใช่ทางเลือกที่กล่าวมาข้างต้น แต่เป็นมาตรการเพิ่มเติม

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

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


2

ฉันจะใช้พวกเขาดังนี้

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

1

ฉันเคยได้ยินว่า XML รวมคุณสมบัติที่เลวร้ายที่สุดของข้อความ (ยาก / ช้าในการประมวลผล) และไบนารี (อ่านไม่ได้)


ไม่ใช่คำตอบที่สมบูรณ์
Anto
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.