เรื่องเล่าที่ไม่ค่อยมีใครรู้ของ SQLite

xguru · 2021-07-05T10:21:01+09:00

สรุปพอดแคสต์สัมภาษณ์ Richard Hipp ผู้พัฒนา SQLite (38 นาที, มีสคริปต์) งานประจำของเขาคือเป็นนักพัฒนาซอฟต์แวร์สำหรับเรือพิฆาตของกองทัพเรือสหรัฐฯ → Informix ที่ใช้ภายในเรือมีข้อผิดพลาดบ่อย เซิร์ฟเวอร์ล่ม และการเชื่อมต่อขาดหายเป็นประจำ → เพราะเป็นเรือรบ ต่อให้เสียหายระหว่างการสู้รบก็ต้องทำงานได้อย่างทนทาน โดยไม่ให้มีป๊อปอัปว่า “ไม่สามารถเชื่อมต่อฐานข้อมูลได้” ไม่จำเป็นต้องมีทรานแซกชัน และต้องสามารถโหลดข้อมูลเข้าสู่ RAM ได้ไม่ว่าสถานการณ์ใด → เขาลองหา SQL DB engine ที่ทำงานได้โดยไม่ต้องมีเซิร์ฟเวอร์ แต่ไม่พบ จึงตัดสินใจสร้างเอง SQLite V1 (ปี 2000) เขียน bytecode engine ที่มองคำสั่ง SQL เป็นโปรแกรม แล้วคอมไพล์และรันคิวรี ไม่ได้ถูกใช้งานจริงในโปรเจ็กต์นั้น (เพราะลูกค้าต้องการใช้ Informix) ใช้มันเพื่อการพัฒนา แล้วเผยแพร่บนอินเทอร์เน็ต ก่อนจะมีคนเริ่มนำไปใช้ เริ่มเห็นข้อความอย่าง “ผมรัน SQL DB บน Palm Pilot ได้แล้ว” ซึ่งดึงดูดความสนใจของผู้คน และเป็นแรงผลักดันให้พัฒนาต่อ Motorola ช่วงปี 2001~2002 Motorola โทรมาบอกว่าจะใส่ SQLite ลงใน OS มือถือใหม่ของตน โดยเสนอว่าจะจ่ายเงินหากรองรับฟีเจอร์ที่ต้องการ เขาเพิ่งรู้ตอนนั้นเองว่าโอเพนซอร์สสามารถทำเงินได้ ราว $80,000 ซึ่งเมื่อเทียบกับปัจจุบันอาจไม่มาก แต่สำหรับเขาเป็นจำนวนที่น่าตกใจมาก เขาทำโปรเจ็กต์นี้ร่วมกับเพื่อนร่วมงานอีกสามคน และนั่นคือจุดเริ่มต้น America Online Phones จากนั้น AOL ก็เป็นรายถัดมาที่ติดต่อมา เป็นยุคที่ยังส่ง CD ทางไปรษณีย์กันอยู่ และใน CD นั้นจำเป็นต้องมีฐานข้อมูล พวกเขาจึงต้องการใส่ SQLite ลงใน CD และต้องการฟีเจอร์ใหม่เพิ่มเติม Symbian OS และ Nokia เดินทางไปลอนดอนเพื่อประชุมในช่วง Thanksgiving (เพราะอังกฤษไม่มีวัน Thanksgiving) พวกเขาต้องการฐานข้อมูลสำหรับ Symbian OS และมีการแข่งขันกับฐานข้อมูลอื่น ๆ (โอเพนซอร์ส 2 ตัว และเชิงพาณิชย์ 7 ตัว) ฐานข้อมูลอีก 9 ตัวได้รับโอกาสให้จูนประสิทธิภาพ แต่สุดท้าย SQLite เป็นผู้ชนะ Bus Factor [1] และ consortium Bus factor คือดัชนีที่หมายถึง ถ้ามีคนในทีมโดนรถบัสชนกี่คน โปรเจ็กต์ถึงจะหยุดชะงัก แม้ตัวเขาจะทำงานเต็มเวลาร่วมกับหลายคนอยู่แล้ว แต่ฝั่ง Symbian บอกว่าควรเพิ่ม bus factor จึงเกิดแนวคิดตั้ง SQLite Consortium เพื่อสนับสนุนเงินทุนให้โปรเจ็กต์และให้คนเข้ามามีส่วนร่วมระยะยาวมากขึ้น เขาเคยเสนอไอเดียสุดโต่งว่าให้สมาชิก consortium ทุกคนมีสิทธิ์โหวต Mitchell Baker จาก Mozilla Foundation ได้ยินเรื่องนี้จากที่ไหนสักแห่งแล้วโทรมา → “Richard คุณกำลังทำผิดทั้งหมด เดี๋ยวฉันจะบอกวิธีตั้ง consortium ให้” → เธอเริ่มวางกติกา → “นักพัฒนาต้องเป็นผู้มีอำนาจควบคุม การตัดสินใจของพวกเขาคือข้อสรุปสุดท้าย แค่เข้าร่วมแล้วจะมีสิทธิ์โหวตไม่ได้” → “บริษัทที่ใช้สิ่งนี้จะได้เกียรติจากการสนับสนุนเงิน แต่การตัดสินใจสุดท้ายต้องเป็นของคุณ” → เธอเด็ดขาดมาก และจัดระบบทุกอย่างให้เรียบร้อย เธอเป็นทนายความ Richard ถามว่า “แล้วจะทำอย่างไรให้คนเข้าร่วม? แรงจูงใจคืออะไร?” → “ไม่ต้องกังวล พวกเขาจะเข้าร่วมเอง และถ้าทำแบบนี้ Mozilla จะเป็นสมาชิกผู้ก่อตั้งด้วย” ด้วยการสนับสนุนจาก Mozilla, Symbian และ Adobe จึงเริ่ม consortium กับทั้งสามบริษัท → ตอนแรกเมื่อ Symbian บอกว่าจำเป็นต้องมี consortium เขาไม่รู้เลยว่าต้องทำอย่างไร และก็ไม่รู้ว่า Mitchell Baker ได้ยินเรื่องนี้แล้วโทรมาได้อย่างไร แต่มันเป็นการเดินทางที่น่าทึ่งมาก Enter Android : จุดเริ่มต้นของ Android เนื่องจากสมาร์ตโฟนทุกเครื่องใช้ SQLite Richard จึงได้เห็นการพัฒนาสมาร์ตโฟนยุคแรกในแทบทุกมิติ ในปี 2005 เขาเข้าประชุมกับ Android ตอนนั้นยังไม่มีทั้ง Android และ iPhone ออกสู่ตลาด เขาดีบัก SQLite บนโทรศัพท์ที่หน้าตาคล้าย BlackBerry มีจอเล็กด้านบนและคีย์บอร์ด QWERTY เต็มรูปแบบ การดีบักด้วย GDB บนโทรศัพท์ที่เชื่อมต่อกับเครือข่ายจริงเป็นประสบการณ์ที่น่าทึ่ง ตอนนั้นยังไม่มีใครใน Motorola, Symbian หรือ Nokia ทำแบบนั้น และเขารู้ได้ทันทีว่า Android จะกลายเป็นยักษ์ใหญ่ Guy, This Is Important : ทุกคน นี่สำคัญมาก ในยุคนั้นผู้ผลิตรายอื่นมีรอบอัปเดตฮาร์ดแวร์และซอฟต์แวร์ที่ยาวมาก ราว 30 วัน แต่ Android ใส่ OS เวอร์ชันใหม่ลงโทรศัพท์ที่เชื่อมต่อเครือข่ายจริงวันละหลายครั้ง โทรศัพท์ Android ต้นแบบที่เขาได้มาภายใต้ NDA มีเคสที่ดูเหมือนพิมพ์ด้วย 3D printer แต่ก็พกพาได้จริง → ของบริษัทอื่นยังเป็นเพียง breadboard ขนาดใหญ่กับต้นแบบที่ไม่ได้เชื่อมต่อเครือข่าย จนไม่อาจใช้เป็นโทรศัพท์ได้จริง เขาอยากบอกคนที่ Motorola และ Symbian ว่า “นี่สำคัญมาก ต้องรีบแก้ปัญหานี้” แต่พูดไม่ได้เพราะ NDA และนั่นเองที่สร้างความแตกต่าง Testing and Aviation Standards : การทดสอบและมาตรฐานการบิน Adam (ผู้สัมภาษณ์): “ตอนนี้ฐานข้อมูลของ Richard อยู่ในสถานะที่คึกคักมาก มีทั้งพรสวรรค์และทีมที่เก่ง แต่ก็ยังเป็นบริษัทที่ปรึกษาซอฟต์แวร์ขนาด 1~4 คน ที่รองรับฐานข้อมูลซึ่งอยู่ในโทรศัพท์ Android ทุกเครื่อง นักพัฒนาจริงจังกับฐานข้อมูลมาก และเกลียดการที่ข้อมูลเกิดปัญหา” เราเคยอวดกับทุกคนแบบไร้เดียงสาว่า SQLite ไม่มีบั๊ก แต่ Android พิสูจน์ชัดเจนว่าเราคิดผิด เขาคิดว่าซอฟต์แวร์ไร้บั๊กเป็นสิ่งที่สร้างได้ แต่เมื่อซอฟต์แวร์ถูกติดตั้งลงในอุปกรณ์นับล้าน ก็เป็นเรื่องน่าตกใจว่าบั๊กเกิดขึ้นได้มากเพียงใด ช่วงนั้นเขาทำงานกับ Rockwell Collins ซึ่งเป็นบริษัท avionics และพวกเขาแนะนำแนวคิด DO-178B [2] ให้ → DO-178B คือมาตรฐานคุณภาพสำหรับผลิตภัณฑ์การบินที่มีความสำคัญด้านความปลอดภัย และต่างจากมาตรฐานคุณภาพอื่นตรงที่ “อ่านรู้เรื่อง” → ราคาหลายร้อยดอลลาร์ แต่เป็นเอกสารบาง ๆ จึงแนะนำให้อ่านสักครั้ง จากนั้นก็เริ่มทำตามกระบวนการของ DO-178B จริงจัง ซึ่งหนึ่งในนั้นคือ 100% MCDC Test Coverage MCDC (Modified Condition / Decision Coverage) [3] คือการทดสอบที่ต้องให้แต่ละเงื่อนไขย่อยผ่านแขนงการตัดสินใจอย่างน้อยหนึ่งครั้ง กว่า SQLite จะได้ MCDC 100% ใช้เวลา 1 ปีเต็ม ที่ชั่วโมงทำงาน 60 ชั่วโมงต่อสัปดาห์ มันยากมาก ต้องทำวันละ 12 ชั่วโมงและเหนื่อยมาก การได้ test coverage 90~95% นั้นง่าย แต่ 5% ที่เหลือนั้นยากมาก อย่างไรก็ตามหลังจากทำเช่นนั้นอยู่ 1 ปีและไปถึง 100% ในที่สุด รายงานบั๊กจาก Android ก็หยุดมา ตั้งแต่นั้นมันก็เริ่มทำงานได้จริง และสร้างความแตกต่างอย่างมาก หลังจากนั้นอีก 8~9 ปีก็ไม่มีบั๊ก การทดสอบนับพันล้านครั้ง ชุดแรกเขียนด้วย TCL (Tool Command Language) และเป็นการทดสอบแบบนักพัฒนาทั่วไป จนถึงตอนนี้ ชุดทดสอบ TCL ชุดแรกยังคงได้รับการบำรุงรักษาและเปิดเผยสาธารณะ แม้จะไม่ถึง 100% แต่ครอบคลุมการทดสอบฟีเจอร์ของ SQLite อย่างละเอียด ส่วน MCDC 100% coverage เรียกว่า TH3 และไม่เปิดเผยต่อสาธารณะ (proprietary) เขาเคยคิดจะขายสิ่งนี้ให้บริษัทด้านการบินเพื่อหารายได้ แต่ขายไม่ได้แม้แต่ชุดเดียว จึงไม่ช่วยในแง่นั้นนัก.. แต่มันช่วยให้ผลิตภัณฑ์ของพวกเขาแข็งแกร่งมาก และทำให้เพิ่มฟีเจอร์ใหม่กับแก้บั๊กได้อย่างรวดเร็ว นับจำนวนการทดสอบได้ยาก แต่มีการทดสอบเดี่ยว 100,000 รายการที่ถูกทำให้เป็นพารามิเตอร์ จนรันรวมกันเป็นการทดสอบหลายพันล้านครั้ง มีเช็กลิสต์ และก่อนปล่อยเวอร์ชันจะทดสอบอย่างน้อย 3 วัน ตั้งใจทดสอบบนหลายระบบปฏิบัติการ → ทุกวันนี้อุปกรณ์แทบทั้งหมดเป็น little-endian แต่สมัยก่อนมี big-endian อยู่มาก จึงทดสอบ big-endian บน PowerPC iBook → ทดสอบบนแพลตฟอร์ม 32 บิต, ARM, Intel, แพลตฟอร์ม 64 Bit, Windows, Linux, Mac, OpenBSD และทุกแพลตฟอร์มกับ OS ที่พอจะทำได้ → มี test suite หลายแบบ ทั้ง TCL เดิม, TH3 และยังมี fuzzer (fuzz testing) ที่รันต่อเนื่องด้วย ยังมี SQL Logic test อีกด้วย → เป็นกองมหึมาของคำสั่ง SQL ที่ Shane Harrelson สร้างไว้เมื่อ 10 ปีก่อน → เขาเอาไปทดสอบกับทุกฐานข้อมูลที่แตะต้องได้ และทุก DB engine ต่างก็ให้คำตอบไม่ได้หรือเกิด segmentation fault รวมถึง SQLite ด้วย ยกเว้น Postgres → มีเพียง Postgres ที่ให้ผลลัพธ์ได้เสมอและหาข้อบกพร่องไม่เจอ นักพัฒนา Postgres บอกว่าเป็นเพราะเราไม่พยายามมากพอ.. แม้อาจเป็นไปได้ว่าเราจะทำให้ Postgres พังได้ แต่เราประทับใจมาก → แม้แต่ Oracle เวอร์ชันเชิงพาณิชย์ก็แครช และ DB2 ก็แครชเช่นกัน → ประเด็นสำคัญคือทำให้ SQLite ให้คำตอบเหมือนกันกับทุกคิวรีเหล่านี้ Building From First Principles ตอนเริ่มเขียนครั้งแรก เขาพยายามหาว่ามีเอกสารอ้างอิงเกี่ยวกับการสร้าง SQL DB engine หรือไม่ แต่ไม่พบ จึงต้องสร้างขึ้นเอง และเป็นภารกิจที่อิสระอย่างแท้จริง มีทฤษฎีมากมายเกิดขึ้นที่ MIT, Harvard และ Berkeley แต่ถ้าไม่ได้อยู่ในมหาวิทยาลัยเหล่านั้น คุณจะไม่รู้ด้วยซ้ำว่าทฤษฎีเหล่านั้นมีอยู่ และก็ไม่รู้จะหามันอย่างไร Volcano model ที่ Postgres ใช้กับ Byte Code model ที่ SQLite ใช้ เมื่อลองดูจริง ๆ แล้วเราทุกคนกลับมาบรรจบกันที่ไอเดียเดียวกัน แม้จะเริ่มจากจุดที่ต่างกันมาก แต่สุดท้ายเราก็มาบรรจบกันในพื้นที่เดียวกันว่าทำอย่างไรให้มันเร็วขึ้น เขาคิดว่านี่เป็นการยืนยันเชิงทฤษฎีอย่างหนึ่ง ว่าสายการพัฒนาที่เป็นอิสระสองสายกลับได้คำตอบเดียวกัน ยกตัวอย่างเช่น เขาไม่รู้เรื่อง Covering Index เลย จนกระทั่งไปงาน PHP conference ที่เยอรมนี ซึ่ง David Axmark แห่ง MySQL ก็ไปพูดด้วย → ในบรรยายครั้งนั้น เขาอธิบายว่า MySQL สร้าง Covering Index อย่างไร → เมื่อ index ของฐานข้อมูลมีหลายคอลัมน์ ถ้าคิวรีใช้เฉพาะคอลัมน์ด้านหน้าของ index และคำตอบอยู่ในคอลัมน์ที่เหลือ DB ก็สามารถตอบจาก index อย่างเดียวได้โดยไม่ต้องไปอ่านตารางต้นฉบับ จึงทำงานได้เร็วขึ้น → ดังนั้นระหว่างนั่งเครื่องกลับบ้าน เมื่อมีผู้โดยสารไม่มาก เขาจึงเปิดแล็ปท็อปและ implement covering index ของ SQLite กลางมหาสมุทรแอตแลนติก B-Trees and The Art of Computer Programming หลายอย่างต้องสร้างขึ้นเองทั้งหมด ไม่มีใครเคยสอนเขาเรื่อง B-Tree เขาแค่เคยได้ยินชื่อเท่านั้น ตอนจะพัฒนา B-tree เอง เขาเห็น TAOCP ของ Don Knuth บนชั้นหนังสือ จึงเปิดหาหัวข้อ B-tree และ Knuth ก็อธิบายอัลกอริทึมไว้ ที่น่าสนุกคือ ในหนังสืออธิบายอัลกอริทึมสำหรับค้นหาและแทรกใน B-tree อย่างละเอียด แต่ไม่มีอัลกอริทึมการลบ มันอยู่ในแบบฝึกหัดท้ายบท ดังนั้นก่อนจะสร้าง B-tree ของตัวเอง เขาต้องแก้โจทย์นั้นก่อน “ขอบคุณนะ Don ขอบคุณจริง ๆ” คนยุคนี้อย่างน้อยก็ควรอ่านหรืออย่างน้อยก็เปิดผ่าน TAOCP ดูบ้าง Freedom to Build It Yourself : อิสระในการสร้างด้วยตัวเอง SQLite ไม่พึ่งพาสิ่งใดเลยนอกจากสิ่งที่ Richard สร้างเอง (ยกเว้น C compiler และ libc) เขายังสร้างระบบ version control และ bug tracker เองด้วย และสิ่งนี้มอบอิสรภาพให้เขา Freedom หมายถึงการดูแลตัวเองได้ด้วยตัวเอง คนที่แบกเป้ท่องเที่ยวพร้อมของใช้จำเป็นทั้งหมดไว้บนหลังแล้วบอกว่าตัวเองเป็นอิสระ ก็เพราะพวกเขาดูแลตัวเองได้ หากสร้างทุกอย่างเอง ก็จะไม่ถูกผูกติดกับใคร และนั่นคืออิสรภาพที่อยู่ภายในมัน สมมติว่า SQLite 2 เลือก Berkeley DB เป็น storage engine → ในตอนนั้น Berkeley DB เป็นโอเพนซอร์ส แต่ภายหลังถูกขายให้ Oracle และกลายเป็นโมเดล proprietary แบบ dual-source ทำให้ไม่สามารถได้ซอร์สโค้ดเวอร์ชันล่าสุดโดยไม่จ่ายค่าไลเซนส์ ตอนนี้ parser generator ของ SQLite ไม่ได้ใช้ Yak หรือ Bison แต่ใช้ตัวที่เขาเขียนเองชื่อ Lemon จึงสามารถแก้ไขได้เองเมื่อต้องการฟีเจอร์ภาษาใหม่ โดยไม่ต้องผูกติดกับเครื่องมือเหล่านั้น ช่วงต้นยุค 2000 ทุกโปรเจ็กต์ใช้ CVS เขาก็ใช้ตามนั้น แต่เมื่อเข้าสู่กลางยุค 2000 แนวคิด distributed version control ก็เริ่มเกิดขึ้น การสร้าง Fossil หลังจากดู Git และ Mercurial และสรุป requirement แล้ว เขาก็ตัดสินใจพัฒนาระบบ version control ของตนเอง ตอนนี้ Fossil ทำงานได้ดีมากจนกลายเป็นโปรเจ็กต์ของตัวเองไปแล้ว Linus Torvalds สร้าง Git ขึ้นเพื่อรองรับการพัฒนา Linux Kernel ดังนั้นถ้าคุณทำงานเกี่ยวกับ Linux Kernel, Git คือระบบ version control ที่สมบูรณ์แบบ ส่วน Fossil คือระบบ version control ที่เหมาะกับงาน SQLite พอดี เพราะเขาสร้างมันเอง จึงตอบโจทย์ความต้องการของเขาได้อย่างแม่นยำ การสร้างขึ้นเองทำให้ควบคุมชะตาของตัวเองได้ มีอิสระมากขึ้น และไม่ต้องพึ่งพาบุคคลที่สาม การพึ่งพาตัวเอง คนที่ออกจากเมืองไปปลูกอาหารกินเองและใช้ชีวิตด้วยตัวเองเรียกว่าอะไร? Survivalist (นักเอาตัวรอด)? หรือ Prepper (ผู้เตรียมพร้อม)? “อย่างที่คุณคงเห็นระหว่างที่ติดต่อกับผม Gmail ของผมมีอาการแปลก ๆ เล็กน้อย อีเมลเด้งกลับอยู่เรื่อย ๆ เพราะงั้นผมกำลังจะทำ mail server ของตัวเอง ตอนที่เรากำลังนัดประชุมกัน ผมก็ยังเขียนโน้ตเกี่ยวกับเรื่องนี้อยู่ มันคงไม่ยากไปกว่าการเขียน DB engine แต่ผมไม่อยากถูกผูกติดกับ Gmail ผมไม่อยากให้พวกเขาควบคุมชะตาของผม ผมไม่อยากให้พวกเขาควบคุมบันทึกการสนทนาทั้งหมดของผม ผมอยากควบคุมมันด้วยตัวเอง เพราะงั้นแม้มันจะยุ่งยากและมีงานให้ทำมาก ผมก็จะพยายามหาทางออกที่ผมควบคุมได้เอง ผมสามารถเช่า virtual machine บนคลาวด์มารันมันได้ โดยไม่ต้องพึ่งพาบุคคลที่สาม” ถ้ามีใครมาบอกว่าจะช่วยแก้ปัญหาให้คุณ คุณต้องรู้ไว้ว่าพวกเขากำลังจะพรากอิสรภาพของคุณไป “ถ้าอยากเป็นอิสระ คุณต้องลงมือทำเอง” คำแนะนำสำหรับคนอื่น ผมเริ่มต้นจากไอเดียบ้าบอว่าจะสร้าง DB engine ที่อ่านและเขียนจากดิสก์ได้โดยตรงโดยไม่ต้องมีเซิร์ฟเวอร์ ถ้าไปถามผู้เชี่ยวชาญ พวกเขาจะบอกว่า “นั่นเป็นไปไม่ได้ มันไม่มีทางทำงานได้ เป็นไอเดียที่โง่มาก” โชคดีที่ผมไม่รู้จักผู้เชี่ยวชาญแบบนั้น ผมเลยแค่ลงมือทำ และเรื่องเหล่านี้ก็เกิดขึ้น อย่าไปฟังผู้เชี่ยวชาญมากนัก จงทำสิ่งที่สมเหตุสมผล และแก้ปัญหาของคุณเอง -- [1] Bus Factor : ระดับความเสี่ยงที่ทีมอาจเข้าสู่ภาวะวิกฤต หากสมาชิกทีมถูก “รถบัสชน” เป็นตัวชี้วัดความเสี่ยงที่เกิดจากการไม่แบ่งปันข้อมูลและหน้าที่ระหว่างสมาชิกทีม ยิ่งค่านี้สูง ข้อมูลก็ยิ่งถูกกระจาย และงานจะไม่ไปกองอยู่กับคนใดคนหนึ่ง [2] DO-178B : Software Considerations in Airborne Systems and Equipment Certification FAA นำไปใช้เป็นแนวทางพิสูจน์ความเหมาะสมสำหรับการรับรองซอฟต์แวร์ด้านการบิน [3] MCDC : Modified Condition / Decision Coverage วิธีออกแบบ test case เมื่อมีหลายเงื่อนไข โดยให้แต่ละเงื่อนไขย่อยมีผลต่อผลลัพธ์สุดท้ายของเงื่อนไขรวมอย่างอิสระ โดยไม่ถูกครอบงำจากเงื่อนไขอื่น

(corecursive.com)

47 คะแนน โดย xguru 2021-07-05 | 16 ความคิดเห็น | แชร์ทาง WhatsApp

สรุปพอดแคสต์สัมภาษณ์ Richard Hipp ผู้พัฒนา SQLite (38 นาที, มีสคริปต์)
งานประจำของเขาคือเป็นนักพัฒนาซอฟต์แวร์สำหรับเรือพิฆาตของกองทัพเรือสหรัฐฯ
→ Informix ที่ใช้ภายในเรือมีข้อผิดพลาดบ่อย เซิร์ฟเวอร์ล่ม และการเชื่อมต่อขาดหายเป็นประจำ
→ เพราะเป็นเรือรบ ต่อให้เสียหายระหว่างการสู้รบก็ต้องทำงานได้อย่างทนทาน โดยไม่ให้มีป๊อปอัปว่า “ไม่สามารถเชื่อมต่อฐานข้อมูลได้”
ไม่จำเป็นต้องมีทรานแซกชัน และต้องสามารถโหลดข้อมูลเข้าสู่ RAM ได้ไม่ว่าสถานการณ์ใด
→ เขาลองหา SQL DB engine ที่ทำงานได้โดยไม่ต้องมีเซิร์ฟเวอร์ แต่ไม่พบ จึงตัดสินใจสร้างเอง

SQLite V1 (ปี 2000)

เขียน bytecode engine ที่มองคำสั่ง SQL เป็นโปรแกรม แล้วคอมไพล์และรันคิวรี
ไม่ได้ถูกใช้งานจริงในโปรเจ็กต์นั้น (เพราะลูกค้าต้องการใช้ Informix)
ใช้มันเพื่อการพัฒนา แล้วเผยแพร่บนอินเทอร์เน็ต ก่อนจะมีคนเริ่มนำไปใช้
เริ่มเห็นข้อความอย่าง “ผมรัน SQL DB บน Palm Pilot ได้แล้ว” ซึ่งดึงดูดความสนใจของผู้คน และเป็นแรงผลักดันให้พัฒนาต่อ

Motorola

ช่วงปี 2001~2002 Motorola โทรมาบอกว่าจะใส่ SQLite ลงใน OS มือถือใหม่ของตน
โดยเสนอว่าจะจ่ายเงินหากรองรับฟีเจอร์ที่ต้องการ
เขาเพิ่งรู้ตอนนั้นเองว่าโอเพนซอร์สสามารถทำเงินได้
ราว $80,000 ซึ่งเมื่อเทียบกับปัจจุบันอาจไม่มาก แต่สำหรับเขาเป็นจำนวนที่น่าตกใจมาก
เขาทำโปรเจ็กต์นี้ร่วมกับเพื่อนร่วมงานอีกสามคน และนั่นคือจุดเริ่มต้น

America Online Phones

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

Symbian OS และ Nokia

เดินทางไปลอนดอนเพื่อประชุมในช่วง Thanksgiving (เพราะอังกฤษไม่มีวัน Thanksgiving)
พวกเขาต้องการฐานข้อมูลสำหรับ Symbian OS และมีการแข่งขันกับฐานข้อมูลอื่น ๆ (โอเพนซอร์ส 2 ตัว และเชิงพาณิชย์ 7 ตัว)
ฐานข้อมูลอีก 9 ตัวได้รับโอกาสให้จูนประสิทธิภาพ แต่สุดท้าย SQLite เป็นผู้ชนะ

Bus Factor [1] และ consortium

Bus factor คือดัชนีที่หมายถึง ถ้ามีคนในทีมโดนรถบัสชนกี่คน โปรเจ็กต์ถึงจะหยุดชะงัก
แม้ตัวเขาจะทำงานเต็มเวลาร่วมกับหลายคนอยู่แล้ว แต่ฝั่ง Symbian บอกว่าควรเพิ่ม bus factor
จึงเกิดแนวคิดตั้ง SQLite Consortium เพื่อสนับสนุนเงินทุนให้โปรเจ็กต์และให้คนเข้ามามีส่วนร่วมระยะยาวมากขึ้น
เขาเคยเสนอไอเดียสุดโต่งว่าให้สมาชิก consortium ทุกคนมีสิทธิ์โหวต
Mitchell Baker จาก Mozilla Foundation ได้ยินเรื่องนี้จากที่ไหนสักแห่งแล้วโทรมา
→ “Richard คุณกำลังทำผิดทั้งหมด เดี๋ยวฉันจะบอกวิธีตั้ง consortium ให้”
→ เธอเริ่มวางกติกา
→ “นักพัฒนาต้องเป็นผู้มีอำนาจควบคุม การตัดสินใจของพวกเขาคือข้อสรุปสุดท้าย แค่เข้าร่วมแล้วจะมีสิทธิ์โหวตไม่ได้”
→ “บริษัทที่ใช้สิ่งนี้จะได้เกียรติจากการสนับสนุนเงิน แต่การตัดสินใจสุดท้ายต้องเป็นของคุณ”
→ เธอเด็ดขาดมาก และจัดระบบทุกอย่างให้เรียบร้อย เธอเป็นทนายความ
Richard ถามว่า “แล้วจะทำอย่างไรให้คนเข้าร่วม? แรงจูงใจคืออะไร?”
→ “ไม่ต้องกังวล พวกเขาจะเข้าร่วมเอง และถ้าทำแบบนี้ Mozilla จะเป็นสมาชิกผู้ก่อตั้งด้วย”
ด้วยการสนับสนุนจาก Mozilla, Symbian และ Adobe จึงเริ่ม consortium กับทั้งสามบริษัท
→ ตอนแรกเมื่อ Symbian บอกว่าจำเป็นต้องมี consortium เขาไม่รู้เลยว่าต้องทำอย่างไร และก็ไม่รู้ว่า Mitchell Baker ได้ยินเรื่องนี้แล้วโทรมาได้อย่างไร แต่มันเป็นการเดินทางที่น่าทึ่งมาก

Enter Android : จุดเริ่มต้นของ Android

เนื่องจากสมาร์ตโฟนทุกเครื่องใช้ SQLite Richard จึงได้เห็นการพัฒนาสมาร์ตโฟนยุคแรกในแทบทุกมิติ
ในปี 2005 เขาเข้าประชุมกับ Android ตอนนั้นยังไม่มีทั้ง Android และ iPhone ออกสู่ตลาด
เขาดีบัก SQLite บนโทรศัพท์ที่หน้าตาคล้าย BlackBerry มีจอเล็กด้านบนและคีย์บอร์ด QWERTY เต็มรูปแบบ
การดีบักด้วย GDB บนโทรศัพท์ที่เชื่อมต่อกับเครือข่ายจริงเป็นประสบการณ์ที่น่าทึ่ง
ตอนนั้นยังไม่มีใครใน Motorola, Symbian หรือ Nokia ทำแบบนั้น และเขารู้ได้ทันทีว่า Android จะกลายเป็นยักษ์ใหญ่

Guy, This Is Important : ทุกคน นี่สำคัญมาก

ในยุคนั้นผู้ผลิตรายอื่นมีรอบอัปเดตฮาร์ดแวร์และซอฟต์แวร์ที่ยาวมาก ราว 30 วัน แต่ Android ใส่ OS เวอร์ชันใหม่ลงโทรศัพท์ที่เชื่อมต่อเครือข่ายจริงวันละหลายครั้ง
โทรศัพท์ Android ต้นแบบที่เขาได้มาภายใต้ NDA มีเคสที่ดูเหมือนพิมพ์ด้วย 3D printer แต่ก็พกพาได้จริง
→ ของบริษัทอื่นยังเป็นเพียง breadboard ขนาดใหญ่กับต้นแบบที่ไม่ได้เชื่อมต่อเครือข่าย จนไม่อาจใช้เป็นโทรศัพท์ได้จริง
เขาอยากบอกคนที่ Motorola และ Symbian ว่า “นี่สำคัญมาก ต้องรีบแก้ปัญหานี้” แต่พูดไม่ได้เพราะ NDA และนั่นเองที่สร้างความแตกต่าง

Testing and Aviation Standards : การทดสอบและมาตรฐานการบิน

Adam (ผู้สัมภาษณ์): “ตอนนี้ฐานข้อมูลของ Richard อยู่ในสถานะที่คึกคักมาก มีทั้งพรสวรรค์และทีมที่เก่ง แต่ก็ยังเป็นบริษัทที่ปรึกษาซอฟต์แวร์ขนาด 1~4 คน ที่รองรับฐานข้อมูลซึ่งอยู่ในโทรศัพท์ Android ทุกเครื่อง นักพัฒนาจริงจังกับฐานข้อมูลมาก และเกลียดการที่ข้อมูลเกิดปัญหา”
เราเคยอวดกับทุกคนแบบไร้เดียงสาว่า SQLite ไม่มีบั๊ก แต่ Android พิสูจน์ชัดเจนว่าเราคิดผิด
เขาคิดว่าซอฟต์แวร์ไร้บั๊กเป็นสิ่งที่สร้างได้ แต่เมื่อซอฟต์แวร์ถูกติดตั้งลงในอุปกรณ์นับล้าน ก็เป็นเรื่องน่าตกใจว่าบั๊กเกิดขึ้นได้มากเพียงใด
ช่วงนั้นเขาทำงานกับ Rockwell Collins ซึ่งเป็นบริษัท avionics และพวกเขาแนะนำแนวคิด DO-178B [2] ให้
→ DO-178B คือมาตรฐานคุณภาพสำหรับผลิตภัณฑ์การบินที่มีความสำคัญด้านความปลอดภัย และต่างจากมาตรฐานคุณภาพอื่นตรงที่ “อ่านรู้เรื่อง”
→ ราคาหลายร้อยดอลลาร์ แต่เป็นเอกสารบาง ๆ จึงแนะนำให้อ่านสักครั้ง
จากนั้นก็เริ่มทำตามกระบวนการของ DO-178B จริงจัง ซึ่งหนึ่งในนั้นคือ 100% MCDC Test Coverage
MCDC (Modified Condition / Decision Coverage) [3] คือการทดสอบที่ต้องให้แต่ละเงื่อนไขย่อยผ่านแขนงการตัดสินใจอย่างน้อยหนึ่งครั้ง
กว่า SQLite จะได้ MCDC 100% ใช้เวลา 1 ปีเต็ม ที่ชั่วโมงทำงาน 60 ชั่วโมงต่อสัปดาห์ มันยากมาก ต้องทำวันละ 12 ชั่วโมงและเหนื่อยมาก
การได้ test coverage 90~95% นั้นง่าย แต่ 5% ที่เหลือนั้นยากมาก อย่างไรก็ตามหลังจากทำเช่นนั้นอยู่ 1 ปีและไปถึง 100% ในที่สุด รายงานบั๊กจาก Android ก็หยุดมา
ตั้งแต่นั้นมันก็เริ่มทำงานได้จริง และสร้างความแตกต่างอย่างมาก หลังจากนั้นอีก 8~9 ปีก็ไม่มีบั๊ก

การทดสอบนับพันล้านครั้ง

ชุดแรกเขียนด้วย TCL (Tool Command Language) และเป็นการทดสอบแบบนักพัฒนาทั่วไป
จนถึงตอนนี้ ชุดทดสอบ TCL ชุดแรกยังคงได้รับการบำรุงรักษาและเปิดเผยสาธารณะ แม้จะไม่ถึง 100% แต่ครอบคลุมการทดสอบฟีเจอร์ของ SQLite อย่างละเอียด
ส่วน MCDC 100% coverage เรียกว่า TH3 และไม่เปิดเผยต่อสาธารณะ (proprietary)
เขาเคยคิดจะขายสิ่งนี้ให้บริษัทด้านการบินเพื่อหารายได้ แต่ขายไม่ได้แม้แต่ชุดเดียว จึงไม่ช่วยในแง่นั้นนัก..
แต่มันช่วยให้ผลิตภัณฑ์ของพวกเขาแข็งแกร่งมาก และทำให้เพิ่มฟีเจอร์ใหม่กับแก้บั๊กได้อย่างรวดเร็ว
นับจำนวนการทดสอบได้ยาก แต่มีการทดสอบเดี่ยว 100,000 รายการที่ถูกทำให้เป็นพารามิเตอร์ จนรันรวมกันเป็นการทดสอบหลายพันล้านครั้ง
มีเช็กลิสต์ และก่อนปล่อยเวอร์ชันจะทดสอบอย่างน้อย 3 วัน
ตั้งใจทดสอบบนหลายระบบปฏิบัติการ
→ ทุกวันนี้อุปกรณ์แทบทั้งหมดเป็น little-endian แต่สมัยก่อนมี big-endian อยู่มาก จึงทดสอบ big-endian บน PowerPC iBook
→ ทดสอบบนแพลตฟอร์ม 32 บิต, ARM, Intel, แพลตฟอร์ม 64 Bit, Windows, Linux, Mac, OpenBSD และทุกแพลตฟอร์มกับ OS ที่พอจะทำได้
→ มี test suite หลายแบบ ทั้ง TCL เดิม, TH3 และยังมี fuzzer (fuzz testing) ที่รันต่อเนื่องด้วย
ยังมี SQL Logic test อีกด้วย
→ เป็นกองมหึมาของคำสั่ง SQL ที่ Shane Harrelson สร้างไว้เมื่อ 10 ปีก่อน
→ เขาเอาไปทดสอบกับทุกฐานข้อมูลที่แตะต้องได้ และทุก DB engine ต่างก็ให้คำตอบไม่ได้หรือเกิด segmentation fault รวมถึง SQLite ด้วย ยกเว้น Postgres
→ มีเพียง Postgres ที่ให้ผลลัพธ์ได้เสมอและหาข้อบกพร่องไม่เจอ นักพัฒนา Postgres บอกว่าเป็นเพราะเราไม่พยายามมากพอ.. แม้อาจเป็นไปได้ว่าเราจะทำให้ Postgres พังได้ แต่เราประทับใจมาก
→ แม้แต่ Oracle เวอร์ชันเชิงพาณิชย์ก็แครช และ DB2 ก็แครชเช่นกัน
→ ประเด็นสำคัญคือทำให้ SQLite ให้คำตอบเหมือนกันกับทุกคิวรีเหล่านี้

Building From First Principles

ตอนเริ่มเขียนครั้งแรก เขาพยายามหาว่ามีเอกสารอ้างอิงเกี่ยวกับการสร้าง SQL DB engine หรือไม่ แต่ไม่พบ จึงต้องสร้างขึ้นเอง และเป็นภารกิจที่อิสระอย่างแท้จริง
มีทฤษฎีมากมายเกิดขึ้นที่ MIT, Harvard และ Berkeley แต่ถ้าไม่ได้อยู่ในมหาวิทยาลัยเหล่านั้น คุณจะไม่รู้ด้วยซ้ำว่าทฤษฎีเหล่านั้นมีอยู่ และก็ไม่รู้จะหามันอย่างไร
Volcano model ที่ Postgres ใช้กับ Byte Code model ที่ SQLite ใช้ เมื่อลองดูจริง ๆ แล้วเราทุกคนกลับมาบรรจบกันที่ไอเดียเดียวกัน
แม้จะเริ่มจากจุดที่ต่างกันมาก แต่สุดท้ายเราก็มาบรรจบกันในพื้นที่เดียวกันว่าทำอย่างไรให้มันเร็วขึ้น
เขาคิดว่านี่เป็นการยืนยันเชิงทฤษฎีอย่างหนึ่ง ว่าสายการพัฒนาที่เป็นอิสระสองสายกลับได้คำตอบเดียวกัน
ยกตัวอย่างเช่น เขาไม่รู้เรื่อง Covering Index เลย จนกระทั่งไปงาน PHP conference ที่เยอรมนี ซึ่ง David Axmark แห่ง MySQL ก็ไปพูดด้วย
→ ในบรรยายครั้งนั้น เขาอธิบายว่า MySQL สร้าง Covering Index อย่างไร
→ เมื่อ index ของฐานข้อมูลมีหลายคอลัมน์ ถ้าคิวรีใช้เฉพาะคอลัมน์ด้านหน้าของ index และคำตอบอยู่ในคอลัมน์ที่เหลือ DB ก็สามารถตอบจาก index อย่างเดียวได้โดยไม่ต้องไปอ่านตารางต้นฉบับ จึงทำงานได้เร็วขึ้น
→ ดังนั้นระหว่างนั่งเครื่องกลับบ้าน เมื่อมีผู้โดยสารไม่มาก เขาจึงเปิดแล็ปท็อปและ implement covering index ของ SQLite กลางมหาสมุทรแอตแลนติก

B-Trees and The Art of Computer Programming

หลายอย่างต้องสร้างขึ้นเองทั้งหมด ไม่มีใครเคยสอนเขาเรื่อง B-Tree เขาแค่เคยได้ยินชื่อเท่านั้น
ตอนจะพัฒนา B-tree เอง เขาเห็น TAOCP ของ Don Knuth บนชั้นหนังสือ จึงเปิดหาหัวข้อ B-tree และ Knuth ก็อธิบายอัลกอริทึมไว้
ที่น่าสนุกคือ ในหนังสืออธิบายอัลกอริทึมสำหรับค้นหาและแทรกใน B-tree อย่างละเอียด แต่ไม่มีอัลกอริทึมการลบ มันอยู่ในแบบฝึกหัดท้ายบท ดังนั้นก่อนจะสร้าง B-tree ของตัวเอง เขาต้องแก้โจทย์นั้นก่อน “ขอบคุณนะ Don ขอบคุณจริง ๆ”
คนยุคนี้อย่างน้อยก็ควรอ่านหรืออย่างน้อยก็เปิดผ่าน TAOCP ดูบ้าง

Freedom to Build It Yourself : อิสระในการสร้างด้วยตัวเอง

SQLite ไม่พึ่งพาสิ่งใดเลยนอกจากสิ่งที่ Richard สร้างเอง (ยกเว้น C compiler และ libc) เขายังสร้างระบบ version control และ bug tracker เองด้วย และสิ่งนี้มอบอิสรภาพให้เขา
Freedom หมายถึงการดูแลตัวเองได้ด้วยตัวเอง
คนที่แบกเป้ท่องเที่ยวพร้อมของใช้จำเป็นทั้งหมดไว้บนหลังแล้วบอกว่าตัวเองเป็นอิสระ ก็เพราะพวกเขาดูแลตัวเองได้
หากสร้างทุกอย่างเอง ก็จะไม่ถูกผูกติดกับใคร และนั่นคืออิสรภาพที่อยู่ภายในมัน
สมมติว่า SQLite 2 เลือก Berkeley DB เป็น storage engine
→ ในตอนนั้น Berkeley DB เป็นโอเพนซอร์ส แต่ภายหลังถูกขายให้ Oracle และกลายเป็นโมเดล proprietary แบบ dual-source ทำให้ไม่สามารถได้ซอร์สโค้ดเวอร์ชันล่าสุดโดยไม่จ่ายค่าไลเซนส์
ตอนนี้ parser generator ของ SQLite ไม่ได้ใช้ Yak หรือ Bison แต่ใช้ตัวที่เขาเขียนเองชื่อ Lemon จึงสามารถแก้ไขได้เองเมื่อต้องการฟีเจอร์ภาษาใหม่ โดยไม่ต้องผูกติดกับเครื่องมือเหล่านั้น
ช่วงต้นยุค 2000 ทุกโปรเจ็กต์ใช้ CVS เขาก็ใช้ตามนั้น แต่เมื่อเข้าสู่กลางยุค 2000 แนวคิด distributed version control ก็เริ่มเกิดขึ้น

การสร้าง Fossil

หลังจากดู Git และ Mercurial และสรุป requirement แล้ว เขาก็ตัดสินใจพัฒนาระบบ version control ของตนเอง
ตอนนี้ Fossil ทำงานได้ดีมากจนกลายเป็นโปรเจ็กต์ของตัวเองไปแล้ว
Linus Torvalds สร้าง Git ขึ้นเพื่อรองรับการพัฒนา Linux Kernel ดังนั้นถ้าคุณทำงานเกี่ยวกับ Linux Kernel, Git คือระบบ version control ที่สมบูรณ์แบบ
ส่วน Fossil คือระบบ version control ที่เหมาะกับงาน SQLite พอดี เพราะเขาสร้างมันเอง จึงตอบโจทย์ความต้องการของเขาได้อย่างแม่นยำ
การสร้างขึ้นเองทำให้ควบคุมชะตาของตัวเองได้ มีอิสระมากขึ้น และไม่ต้องพึ่งพาบุคคลที่สาม

การพึ่งพาตัวเอง

คนที่ออกจากเมืองไปปลูกอาหารกินเองและใช้ชีวิตด้วยตัวเองเรียกว่าอะไร? Survivalist (นักเอาตัวรอด)? หรือ Prepper (ผู้เตรียมพร้อม)?
“อย่างที่คุณคงเห็นระหว่างที่ติดต่อกับผม Gmail ของผมมีอาการแปลก ๆ เล็กน้อย อีเมลเด้งกลับอยู่เรื่อย ๆ เพราะงั้นผมกำลังจะทำ mail server ของตัวเอง ตอนที่เรากำลังนัดประชุมกัน ผมก็ยังเขียนโน้ตเกี่ยวกับเรื่องนี้อยู่ มันคงไม่ยากไปกว่าการเขียน DB engine แต่ผมไม่อยากถูกผูกติดกับ Gmail ผมไม่อยากให้พวกเขาควบคุมชะตาของผม ผมไม่อยากให้พวกเขาควบคุมบันทึกการสนทนาทั้งหมดของผม ผมอยากควบคุมมันด้วยตัวเอง เพราะงั้นแม้มันจะยุ่งยากและมีงานให้ทำมาก ผมก็จะพยายามหาทางออกที่ผมควบคุมได้เอง ผมสามารถเช่า virtual machine บนคลาวด์มารันมันได้ โดยไม่ต้องพึ่งพาบุคคลที่สาม”
ถ้ามีใครมาบอกว่าจะช่วยแก้ปัญหาให้คุณ คุณต้องรู้ไว้ว่าพวกเขากำลังจะพรากอิสรภาพของคุณไป “ถ้าอยากเป็นอิสระ คุณต้องลงมือทำเอง”

คำแนะนำสำหรับคนอื่น

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

[1] Bus Factor : ระดับความเสี่ยงที่ทีมอาจเข้าสู่ภาวะวิกฤต หากสมาชิกทีมถูก “รถบัสชน”

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

[2] DO-178B : Software Considerations in Airborne Systems and Equipment Certification

FAA นำไปใช้เป็นแนวทางพิสูจน์ความเหมาะสมสำหรับการรับรองซอฟต์แวร์ด้านการบิน

[3] MCDC : Modified Condition / Decision Coverage

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

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

enowy 2025-08-07

มีบทความดี ๆ แบบนี้อยู่ด้วย ดีใจที่ได้อ่านฉบับแปล

mkeasy 2021-07-08

เป็นบทความที่ทำให้อยากกลับมาอ่านซ้ำแล้วซ้ำอีกเลยนะครับ ขอบคุณครับ

ถ้าอยากเป็นอิสระ ก็ต้องลงมือทำเอง

จงทำสิ่งที่สมเหตุสมผล

จงแก้ปัญหาของคุณเอง

edunga1 2021-07-05

เป็นบทความที่น่าสนใจมากจริง ๆ!

"การทำให้ครอบคลุมการทดสอบ 90~95% นั้นง่าย แต่ 5% ที่เหลือนี่ยากมาก อย่างไรก็ตาม เมื่อทำแบบนั้นต่อเนื่องเป็นเวลา 1 ปี จนในที่สุดไปถึง 100% ก็ไม่มีรายงานบั๊กจาก Android เข้ามาอีก"

เป็นไปได้ด้วยสินะ

panarch 2021-07-05

อ่านได้เพลินมาก ขอบคุณครับ!

jsryu 2021-07-05

อ่านได้เพลินมากครับ ขอบคุณครับ

falconer 2021-07-05

อ่านได้ดีมากครับ

gmlwo530 2021-07-05

อ่านสนุกมาก!

kwangyeol 2021-07-05

อ่านได้อย่างเพลิดเพลินมาก ขอบคุณครับ

baeba 2021-07-05

อ่านได้เพลินมากครับ

ดูเหมือนว่าการสรุปย่อจะยากกว่าอีกนะครับ

shaichoi 2021-07-05

อ่านได้เพลินมากครับ ทำให้คิดได้หลายอย่างเลย ขอบคุณครับ :)

fureweb 2021-07-05

อ่านได้เพลินมาก ขอบคุณครับ!

kalihman 2021-07-05

อ่านแล้วครับ

jongpak 2021-07-05

อ่านเพลินจนไม่รู้ว่าเวลาผ่านไปเลยครับ 555

ผมนี่รู้สึกอายเลยที่เคยประเมินต่ำไปว่าเป็นแค่ embedded DB แบบง่าย ๆ ^^;

sixmen 2021-07-05

ตอนแรกก็คิดว่าเป็นแค่ DBMS สำหรับพัฒนาแบบโลคัลธรรมดา ๆ เลยใช้มันไปแบบนั้น แต่จริง ๆ แล้วมันไม่ได้ธรรมดาเลย!!

nicewook 2021-07-05

อ่านเพลินมากครับ

xguru 2021-07-05

ปัจจุบันมี SQLite ที่กำลังใช้งานอยู่ทั่วโลกมากกว่า 1 ล้านล้านชุด

สมาร์ตโฟนทุกเครื่อง (Android, iOS) มากกว่า 4 พันล้านเครื่อง
Mac/Windows
เบราว์เซอร์ FF/Chrome/Safari
PHP/Python
Skype/iTunes/Dropbox/Turbotax
กล่องเซ็ตท็อปบ็อกซ์และทีวีส่วนใหญ่
ระบบมัลติมีเดียในรถยนต์ส่วนใหญ่

https://www.sqlite.org/mostdeployed.html