SQLite เป็นรูปแบบการจัดเก็บที่หอสมุดรัฐสภาสหรัฐอเมริกาแนะนำ

 (sqlite.org)
1 คะแนน โดย GN⁺ 1 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • SQLite รวมอยู่ใน รูปแบบการจัดเก็บ ที่ US Library of Congress แนะนำสำหรับชุดข้อมูล
  • สามารถตรวจสอบข้อมูลอ้างอิงที่เกี่ยวข้องได้จาก คำอธิบายรูปแบบ SQLite ของ Library of Congress และรายการรูปแบบที่แนะนำสำหรับข้อมูล: https://www.loc.gov/preservation/digital/formats/fdd/fdd000461.shtml#local, https://www.loc.gov/preservation/resources/rfs/data.html
  • ณ วันที่ 29 พฤษภาคม 2018 รูปแบบการจัดเก็บที่แนะนำสำหรับชุดข้อมูล นอกจาก SQLite แล้ว มีเพียง XML, JSON, CSV
  • รูปแบบการจัดเก็บที่ Library of Congress แนะนำ คือรูปแบบที่ผู้เชี่ยวชาญด้านการอนุรักษ์มองว่าสามารถเพิ่ม ความอยู่รอด และ การเข้าถึงได้อย่างต่อเนื่อง ของเนื้อหาดิจิทัลให้สูงสุด
  • เกณฑ์การพิจารณารวมถึง ความเปิดกว้าง, ระดับการยอมรับ, ความโปร่งใส, การจัดทำเอกสารในตัวเอง, การพึ่งพาภายนอก, ผลกระทบจากสิทธิบัตร, และกลไกการป้องกันทางเทคนิค เช่น การเข้ารหัส

SQLite และรูปแบบการจัดเก็บที่ LoC แนะนำ

เกณฑ์การพิจารณารูปแบบการจัดเก็บที่แนะนำ

  • รูปแบบการจัดเก็บที่แนะนำ คือรูปแบบที่ผู้เชี่ยวชาญด้านการอนุรักษ์ของ Library of Congress มองว่าสามารถเพิ่ม ความอยู่รอด และ การเข้าถึงได้อย่างต่อเนื่อง ของเนื้อหาดิจิทัลให้สูงสุด
  • Library of Congress พิจารณาเกณฑ์ต่อไปนี้เมื่อเลือกรูปแบบการจัดเก็บที่แนะนำ

  • ความเปิดกว้าง

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

  • ระดับการยอมรับ

    • พิจารณาระดับที่ผู้สร้าง ผู้เผยแพร่ และผู้ใช้งานหลักของทรัพยากรสารสนเทศใช้รูปแบบดังกล่าวอยู่แล้ว
    • รวมถึงกรณีที่ใช้เป็นรูปแบบต้นฉบับ รูปแบบสำหรับส่งมอบให้ผู้ใช้ปลายทาง หรือเป็นวิธีแลกเปลี่ยนระหว่างระบบ

  • ความโปร่งใส

    • พิจารณาว่าสามารถวิเคราะห์การแทนค่าดิจิทัลได้โดยตรงด้วยเครื่องมือพื้นฐานหรือไม่ เช่น มนุษย์สามารถอ่านได้ในโปรแกรมแก้ไขข้อความล้วน

  • การจัดทำเอกสารในตัวเอง

    • วัตถุดิจิทัลที่มีการจัดทำเอกสารในตัวเองจะมีเมทาดาทาคำอธิบายพื้นฐาน เมทาดาทาทางเทคนิค และเมทาดาทาด้านการจัดการอื่น ๆ รวมอยู่ด้วย

  • การพึ่งพาภายนอก

    • พิจารณาระดับการพึ่งพาฮาร์ดแวร์ ระบบปฏิบัติการ หรือซอฟต์แวร์เฉพาะในการเรนเดอร์หรือใช้งาน และความซับซ้อนในการจัดการการพึ่งพานั้นในสภาพแวดล้อมทางเทคโนโลยีในอนาคต

  • ผลกระทบจากสิทธิบัตร

    • พิจารณาว่าสิทธิบัตรขัดขวางความสามารถของหน่วยงานอนุรักษ์ในการดูแลรักษาเนื้อหาในรูปแบบนั้นมากเพียงใด

  • กลไกการป้องกันทางเทคนิค

    • พิจารณาว่ามีการใช้งานกลไกอย่างการเข้ารหัสที่ขัดขวางการอนุรักษ์เนื้อหาในคลังเก็บที่เชื่อถือได้หรือไม่

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 1 시간 전
ความคิดเห็นจาก Hacker News

  • ได้แรงบันดาลใจจาก SQLite อยู่เสมอ โดยรวมชอบมาก แต่ถ้าไม่ได้มีการเขียนข้อมูล มันก็อาจจะเป็นตัวเลือกที่เกินความจำเป็นพอสมควร
    เลยทำฟอร์แมตที่คงไม่ได้มาแทน SQLite แต่ เบาและเร็วกว่าอย่างมาก และทำงานกับไฟล์บีบอัด zstd ได้ด้วย อินเด็กซ์มีขนาดเล็กมาก และเก็บไบนารีหรือข้อความได้เหมือน SQLite
    ส่วน wasm ที่ทำหน้าที่แตกไฟล์ อ่าน และค้นหา มีขนาด 38KB ในแบบไม่บีบอัด และน่าจะราว 16KB แบบ gzip เมื่อเทียบกับ wasm ของ SQLite พร้อม glue code ที่ 1.2MB แล้วถือว่าแค่ 3% ของขนาด แต่ค้นหาและโหลดได้เร็วกว่าเยอะ
    โปรแกรมของฉันไม่ได้เป็นแบบคอลัมน์ และไม่เหมาะกับการจัดการสเปรดชีต แต่เหมาะมากกับ พจนานุกรมและคลังไฟล์ภาพ·เสียง
    ฉันยังพอร์ตตัวถอดรหัส jbig2 เป็นโมดูล wasm ขนาด 17KB ได้ด้วย ทำให้อ่านสแกนขาวดำขนาด 8KB ต่อหน้าได้ และยังพอมองออกว่าเป็นอะไร
    https://github.com/tnelsond/peakslab
    SQLite ออกแบบมาได้ดีมาก ส่วน PeakSlab นั้นเรียบง่ายมาก

    • บอกว่า “wasm ของ SQLite พร้อม glue code 1.2MB” แต่จริง ๆ แล้วแบบมาตรฐานที่ยังไม่ย่อบน trunk ปัจจุบันคือ 1.7MB เอกสารกินพื้นที่เกือบพอ ๆ กับโค้ด JS เลย ทำให้ WASM กับ JS มีขนาดใกล้เคียงกันพอ ๆ กัน แต่ถ้าย่อแล้ว 1.2MB ก็ถูกต้อง
      อนึ่ง ฉันคือคนดูแลตัวนั้นเอง
      ตัวเลขบน trunk ตอนนี้คือ sqlite3.wasm 896745, sqlite3.mjs 816270 (ไม่ย่อรวมเอกสาร), sqlite3.mjs 431388 (ไม่ย่อไม่รวมเอกสาร), sqlite3.mjs 310975 (ย่อ)
    • ไม่เคยรู้จัก PeakSlab มาก่อน แต่มันเท่มากและใหม่ดี ดูเหมือน ประสิทธิภาพด้านพจนานุกรม จะยอดเยี่ยมด้วย ควรค่าแก่การบุ๊กมาร์กไว้กลับมาใช้ภายหลัง
    • ดูใกล้เคียงกับการไปแข่งกับ Berkeley DB แบบสมัยก่อนมากกว่า: https://en.wikipedia.org/wiki/Berkeley_DB
      ตอนนี้เห็นว่าไม่ใช่ BSD license แล้วด้วย และถึงอย่างนั้นก็แทบหายไปเพราะ SQLite แต่เดิมมันถูกใช้เป็นที่เก็บคีย์-แวลูบนดิสก์แบบพื้นฐาน
    • SQLite เองก็เรียบง่ายในแบบของมัน และฉันชอบหลักการออกแบบของ SQL dialect นั้น
      ประมาณว่า “right join ก็เป็นแค่ left join ที่กลับด้าน ดังนั้นไม่จำเป็นต้องมี”
      แน่นอนว่าทำอะไรให้เรียบง่ายกว่านี้หรือเฉพาะทางกว่านี้ได้เสมอ แอปจำนวนมากที่ใช้ฐานข้อมูลน่าจะทำงานได้ดีมากด้วย SQLite อย่างเดียว และบางแอปก็น่าจะพอด้วยแค่ ไฟล์ข้อความ แทนฐานข้อมูลอย่าง SQLite
    • วิธีแก้ที่มาตรฐานกว่าน่าจะเป็น cdb เพียงแต่ไม่รองรับข้อมูลแบบบีบอัด
      https://cdb.cr.yp.to/ , https://en.wikipedia.org/wiki/Cdb_(software)

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

    • ถ้าอย่างนั้นก็สงสัยว่าบริษัทพวกเดียวกันห้าม Excel ด้วยไหม เพราะสเปรดชีต Excel มักกลายเป็นฐานข้อมูลเงาในที่ที่ไม่คาดคิด
    • ถ้าจะคุยกันว่า “อะไรก็กลายเป็นฐานข้อมูลระดับ mission-critical ได้” ควรอ่านโพสต์นี้แบบห้ามพลาด
      https://www.reddit.com/r/sysadmin/comments/eaphr8/a_dropbox_...
    • ถ้าเป็น “ไฟล์ที่ใช้นามสกุลอะไรก็ได้” ก็แค่อ่าน magic number สิ ยังไงก็ไม่ควรเชื่อนามสกุลไฟล์อยู่แล้ว
      ส่วน “อาจถูกคัดลอกไปยังเซิร์ฟเวอร์อื่นได้” นั้น สเปรดชีตก็เหมือนกัน
      ไม่ได้ปฏิเสธว่าการเข้าถึงข้อมูลแบบรวมศูนย์เป็นสิ่งที่พึงประสงค์ แต่ตรรกะนี้ดูยังไม่ละเอียดพอ
    • SQLite ยังมีการใช้งานที่น่าสนใจแบบนี้ด้วย: https://sqlite.org/sqlar.html
    • เพราะงั้นไฟล์คอนฟิกแบบนั้นจึงมักถูกวางไว้ใน AppData หรือไดเรกทอรี dotfile หรือไม่ก็ตำแหน่งที่เทียบเท่ากันใน ~/Library ของ MacOS

  • เมื่อก่อนฉันเคยคิดว่า “SQLite เป็นของเล่นและไว้ใจใช้กับข้อมูลจริงไม่ได้” แต่ตอนนี้เปลี่ยนมาเป็นฝั่ง “ใช้ SQLite กับแทบทุกอย่างกันเถอะ” แล้ว
    ถ้าคุณจัดรูปแบบให้เข้ากับแพตเทิร์น ผู้เขียนคนเดียว ผู้อ่านหลายคน ได้ SQLite จะดีมาก ถ้าใช้การตั้งค่าที่ถูกต้องก็ไม่ทำข้อมูลหาย ซึ่งการตั้งค่านั้นค้นหาแค่ประมาณ 1 นาทีก็เจอ
    ทุกวันนี้แอปส่วนใหญ่ของฉันก็เป็นแค่ Go binary + SQLite + ไฟล์ service ของ systemd
    ยังไม่เคยทำข้อมูลหายเลย ประสิทธิภาพก็ดีเยี่ยม และเพียงพอสำหรับแอปส่วนใหญ่

    • ผู้เขียนคนเดียวจริง ๆ แล้วไม่ได้เป็นปัญหาใหญ่เท่าที่คนชอบพูดกัน ปัจจุบัน ไดรฟ์ NVMe โหดมาก แค่ตั้งค่า WAL ให้เหมาะก็เขียนได้ 5,000 ครั้งต่อวินาทีสบาย ๆ ซึ่งเกินฝันของแอปส่วนใหญ่อยู่แล้ว
      ฉันเคยทำได้ถึง 180,000 ครั้งต่อวินาทีบน VPS ธรรมดา ๆ ด้วยแพตเทิร์นตัวเขียนแบบแบตช์ด้วยซ้ำ
    • อยากรู้ว่าคุณใช้ backend node หลายตัวไหม ถ้าใช่ก็อยากรู้เหมือนกันว่าให้ ไฟล์ SQLite ถูกเข้าถึงจากคนละโหนดได้อย่างไร

  • มันเขียนว่า “ณ เวลาที่เขียนบทความนี้ (2018-05-29) …” ดังนั้นนี่คือข่าวที่เกือบ 8 ปีแล้ว ถึงอย่างนั้นก็ไม่ใช่ว่าจะบ่น เพราะฉันก็ยังไม่เคยรู้มาก่อน เรียกว่าขอบคุณที่เอามาโพสต์มากกว่า
    สมองสายคณิตของฉันรวนไปชั่วครู่เลยคิดว่าเป็น 6 ปี

    • ตอนนี้ปี 2026 แล้ว ก็เลยเป็น 8 ปีก่อน
    • อ่านไปก็รู้สึกเดจาวู

  • ฟอร์แมตการจัดเก็บที่แนะนำในปี 2026: https://www.loc.gov/preservation/resources/rfs/data.html

    • เวลาจัดเก็บข้อมูล ถ้าจะวางแผนยาวไปถึง 300~500 ปีข้างหน้า และทำให้ทนทั้งนวัตกรรมใหม่สารพัดรวมถึงความล้าสมัยทางเทคโนโลยีขั้นพื้นฐานได้ มันต้องใช้การคิดระยะยาวจริง ๆ
      สื่อกระดาษแบบไหนกันนะที่อยู่รอดได้นานที่สุด?
    • เกณฑ์การแนะนำดูค่อนข้างกว้างทีเดียว มี XLS อยู่ในกลุ่ม “preferred” ด้วย

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

    • นักจดหมายเหตุมักชอบฟอร์แมตที่ใกล้ต้นฉบับด้วย และ SQLite ก็ช่วยเก็บ ความสัมพันธ์เชิงสัมพันธ์ ที่แสดงออกเป็น CSV ได้ยากเอาไว้ได้ตรง ๆ

  • ชอบ SQLite และดีใจที่มีการแชร์เรื่องนี้ แต่รู้สึกว่าท้ายพาดหัวควรมี “(2018)”
    เพราะมีประโยคว่า “ณ เวลาที่เขียนบทความนี้ (2018-05-29) ฟอร์แมตการจัดเก็บอื่นที่แนะนำสำหรับชุดข้อมูลมีเพียง XML, JSON, CSV เท่านั้น” อยู่

    • เผื่อไว้เป็นข้อมูล หลังจากนั้นก็มีการเพิ่มฟอร์แมตในรายการอีกมาก
      ในกลุ่มฟอร์แมตที่ preferred จะให้ความสำคัญกับฟอร์แมตข้อความที่เป็นอิสระจากแพลตฟอร์มมากกว่าฟอร์แมต native หรือไบนารี ตราบใดที่ข้อมูลครบถ้วนและยังคงรายละเอียดกับความแม่นยำไว้ได้ รวมถึงมาตรฐานตลาดโดยพฤตินัยที่พัฒนาแล้วและถูกใช้อย่างแพร่หลาย
      ตัวอย่างเช่น ฟอร์แมตที่อิงสคีมาซึ่งเป็นที่รู้จักดีและมีเครื่องมือตรวจสอบแบบเปิด, ฟอร์แมตแบบ line-oriented อย่าง TSV·CSV·fixed-width, และฟอร์แมตเปิดที่ไม่ขึ้นกับแพลตฟอร์มอย่าง .db·.db3·.sqlite·.sqlite3
      นอกจากนี้ยังรวมถึงฟอร์แมตกรรมสิทธิ์ที่เป็นมาตรฐานโดยพฤตินัยในสายอาชีพบางประเภท หรือมีหลายเครื่องมือรองรับ เช่น Excel .xls/.xlsx และ Shapefile
      การเข้ารหัสอักขระจะให้ความสำคัญตามลำดับคือ UTF-8, UTF-16 พร้อม BOM, US-ASCII หรือ ISO 8859-1 และจากนั้นจึงเป็น encoding อื่นที่มีการระบุชื่อ
      ในกลุ่ม allowed สำหรับข้อมูล จะมีฟอร์แมตเปิดที่ไม่เป็นกรรมสิทธิ์ มีเอกสารกำกับ และได้รับการรับรองเป็นมาตรฐานโดยชุมชนเฉพาะทางหรือหน่วยงานรัฐ เช่น CDF, HDF รวมถึงฟอร์แมตข้อมูลแบบข้อความที่มีสคีมาพร้อมใช้งาน
      สำหรับการรวมชุดหรือการส่งต่อ อนุญาตให้ใช้ ZIP, RAR, tar, 7z ที่ไม่มีการเข้ารหัส ไม่มีรหัสผ่าน และไม่มีกลไกป้องกันอื่น ๆ
      https://www.loc.gov/preservation/resources/rfs/data.html

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

    • ไม่ได้คิดว่าสิ่งนี้จะทำให้โลกทัศน์ของคุณพังทลายลงทันทีหรอก แต่เผื่อว่าจะมีประโยชน์กับคุณเหมือนที่มีประโยชน์กับฉัน ลองดู Metabase ได้
      คุณโฮสต์เองได้ และถ้าคุณแค่อยากแสดงข้อมูลให้ผู้มีส่วนได้ส่วนเสียเข้าใจง่าย มันเรียบง่ายมาก แน่นอนว่าถ้าถลำลึกเกินไป คุณอาจเสียใจในทุกการตัดสินใจในชีวิตได้ แต่ฉันพยายามยับยั้งตัวเองไม่ให้ไปถึงจุดนั้น
      https://www.metabase.com/
    • สิ่งที่กวนใจฉันมาตลอดคือ SQLite ต้องอาศัยการพาร์สข้อความเพื่อทำงาน ฉันไม่เข้าใจว่าทำไมต้องเขียนคิวรีเป็นข้อความ ทำไมถึงแสดงเป็น ตรรกะของโปรแกรม ไม่ได้
      ด้วยเหตุนี้ฉันเลยไม่เคยใช้ฐานข้อมูลเชิงสัมพันธ์เลยแม้แต่ครั้งเดียว เพราะฉันไม่ชอบมัน ฉันรู้ว่ามันอาจมีประสิทธิภาพดีกว่าข้อมูลที่มีโครงสร้างล้วน ๆ แต่ฉันเกลียด SQL และแนวคิดของ SQL เอง ไม่อยากเขียน ไม่อยากเรียน และไม่อยากใช้ระบบที่พึ่งมัน
      มันให้ความรู้สึกเหมือนเป็นแนวทางที่ผิดแบบเดียวกับ PHP มีวิธีบรรเทาความรู้สึกนี้ไหม? ฉันไม่อยากเลิกใช้ SQLite ต่อไปเพียงเพราะ SQL แต่ก็รับมันไม่ค่อยได้จริง ๆ ฉันไม่ชอบการสร้างสตริงหรือการมีการพาร์สสตริงอยู่ที่ไหนก็ตามในสแตก มันแค่รู้สึกผิดไปหมด

  • SQLite นั้นอเนกประสงค์อย่างน่าทึ่ง ไม่กี่สัปดาห์ก่อนก็เพิ่งมีการเปิดตัวส่วนขยายที่ทำ คิวระหว่างโปรเซส, สตรีม, publish/subscribe บน SQLite ได้
    Show HN: Honker – Postgres NOTIFY/LISTEN Semantics for SQLite | 327 points | 94 comments | https://news.ycombinator.com/item?id=47874647
    การแจ้งเตือนแบบเรียลไทม์เคยเป็นชิ้นส่วนใหญ่ที่ขาดหายไป หากจะทำทั้งแอปบน backend ของ SQLite และตอนนี้ก็ดูเหมือนมีทางออกที่ค่อนข้างดีแล้ว

  • ดีใจที่เห็น SQLite ได้รับ การยอมรับในระดับสถาบัน แบบนี้ ด้วยความที่เป็นฟอร์แมตไฟล์เดี่ยว การเก็บแบบจดหมายเหตุจึงง่ายกว่าการดัมป์ฐานข้อมูลแบบดั้งเดิมอย่างมหาศาล