SQLite

 

SQLite : บริการจัดการ ง่าย, ใช้ง่าย, ใช้ ในโปรแกรมง่าย, บำรุงรักษาง่าย


คน ใช้ ชอบ เพราะ เล็กและเร็ว แต่นั่นมันแค่บังเอิญ ผู้ใช้ พบว่า ความที่มันเสถียร เชื่อใจได้เป็นผลมาจากความง่าย ไม่ยุ่ง ทำให้ที่จะผิด เกิดได้น้อย ฉนั้น SQLite เล็ก เร็วและใว้ใจได้ แต่ เหนือสิ่งอื่นใด, SQLite พยายามทำให้มัน ง่าย( simple)

ความ ง่ายไม่ยุ่งยาก( simplicity) ของ ตัวขับระบบฐานข้อมูลตัวนี้( database engine) เป็นได้ทั้งข้อดีและข้อด้อย ( strength & weakness) ขึ้นอยู่กับว่า จะเอาไปใช้อะไร การที่ทำให้ง่ายและไม่ยุ่งยากทำให้ ต้องสลัดของบางอย่างที่คนบางคนเห็นว่า เป็นลักษณะเด่น เช่น
  - high concurrency( การมีคนใช้ร่วมกันหลายคนพร้อมกัน)
  - fine-grained access control ( หมายถึงการป้องกัน แบบวิวิสมาหรา) มี function ให้ใช้มากๆ มี stored procedure และ การใช้ SQL command แบบ ลวดลายแปลกๆ XML หรือ Java extension ฯลฯ
หากต้องการใช้ ของที่วิวิสมาหรา และไม่เกี่ยงที่จะใช้วิธีการแปลกๆ ยุ่งยากแล้วละก็ ไม่น่าจะใช้ SQLite
SQLite ไม่ได้ตั้งใจจะเป็นตัวที่จะเอามาใช้ในระดับบริษัทใหญ่ๆ มันไม่ได้ต้องการจะ มาแข่งกับ Oracle หรือ PostgreSQL

กฎง่ายๆ ในการจะเลือกใช้ SQLite คือ หากต้องการ การบริหาร( administration) การใช้( implementation) และการจัดการ( maintanenance) ที่ง่ายและไม่ยุ่งยาก และจริงๆในการทำงานจริงๆแล้ว การทำให้ของใช้ง่ายๆ นั้น เราพบว่า มันเป็นทางออกที่พบบ่อยมาก กว่า ที่พวกเราคิดกันเสียอีก ( ก็คือ เอาของไม่ต้องวิวิสมาหรามาใช้นั้น มันได้ผลดีกว่า ไปเอาของยุ่งยากของใหญ่ มาใช้)



สภาพการ หรือ เหตุการณ์ที่ SQLite ใช้ได้ดี

websites: SQLite รอง รับ เวป ที่มีคนใช้ขนาดต่ำ ถึงขนาดกลาง ( ซึ่งก็รวมแล้ว ก็ประมาณ 99.9% ของเวปไซด์ทั้งหมด --อันนี้ ก็หมายถึง รร ใน สพท รวมทั้งสำนัก สพท เกือบทั้งหมด - ผู้แปล) จำนวน การเข้าใช้ที่เข้ามาเวปไซด์ที่ SQLite สามารถจัดการได้นั้น ขึ้นอยูกับว่า ข้อมูลขนาดใหน โดยทั่วไป ไซด์ใหน ที่มี น้อยกว่า 100,000(แสน) hits/วัน SQLite ควรจะรับได้สบายๆ อันนี้ เป็นการประเมินให้อย่างต่ำ( จริงๆ มันรับได้มากกว่า แสน hits) ได้มีการแสดงว่า SQLite สามารถรับได้ สิบเท่า ของจำนวนนี้

Embedded devices and Applications : เนื่องจากมันเล็ก และไม่ต้องมีการจัดการอะไร( ไม่ต้องมี user name, password -คือ ท่านต้องเขียน โปรแกรมดักเองว่า จะให้ใครเข้ามาได้ ) SQLite จึงใช้ได้ดี ในรายที่ใช้ใน devices หรือ บริการที่ไม่ต้องมีคนมาคอยคุม SQLite ใช้ได้ดีใน cellphone, PDA อุปกรณ์ ที่ตั้งโต้ะ หรือ เครื่องไฟฟ้า เช่น เครือง ไมโครเวป เป็นต้น

Application File Format : อันนี้ ไม่ทราบว่าจะแปลยังไง แปลไม่ออก

Replacement for Ad hoc disk files : ใช้ในราย แทนที่จะ เปิด file เข้าออก ให้ใช้ เขียน เข้า SQLite แทน จะสดวกกว่า

Internal or temporary databases: ข้อมูลที่ต้องการจะ แยก ดูด สกัด ในหลายแบบอย่าง การใช้ ข้อมูลใน memory โดยอาศัย SQL command ต่างๆ จะสดวกกว่า SQLite เนืองจากมันไม่ใหญ่ จึงใช้ได้ในรายเช่นนี้

Command-line dataset analysis tool: การใช้ ข้อมูลจาก command line ( ก็คือ จาก dos prompt ) สามารถจะใช้ SQLite เพื่อ ดึงข้อมูลออกมาดูได้อย่างง่ายและรวดเร็ว ลักษณะอันนี้ จะทำจาก DBMS ตัวใหญ่ ก็ได้ แต่ ข้อได้เปรียบคือ SQLite ติดตั้ง และใช้ ง่ายกว่ามาก ไม่เพียงแค่นั้น SQLite สามารถเอาไปใช้ได้ ด้วย floppy disk แผ่นเดียว ( รวมทั้งข้อมูลด้วย)

Stand-in for an enterprise dataase furint demos or testing: คือ เอาเป็นตัวสำหรับแสดง ให้ดูเช่น ให้เอาข้อมูลของลูกค้ามาแสดง แทนที่จะเอา ฐานข้อมูลตัวใหญ่ มาใช้ เพราะมันสามารถเอาไปใช้แบบ standalone ได้

Database Pedagogy( การใช้เรียน สอน) : หากต้องการจะเรียนรู้การใช้ SQL command ต่างๆ SQLite เป็นตัวที่ใช้ได้ดีมาก เพราะ อย่างที่ว่ามาข้างบน ทำให้นักเรียน เข้าใจการทำงานของระบบ ฐานข้อมูลได้ง่าย



สภาพการณ์ ที่ RDBMS ตัวใหญ่ใช้ได้ดีกว่า

Client/Server Application : เช่นระบบการทำงาน แบบที่ต้องใช้ ข้อมูลมหาศาล และต้องการให้คนใช้ร่วมกันเป็นจำนวนมาก เช่น ผ่าน ระบบเครือข่ายใหญ่ๆ แม้ว่า SQLite จะทำงานผ่าน เครือข่ายได้ก็ตามเนื่องจากมันทำงานแบบ ระบบ file ฉนั้น จะทำให้สู้ ระบบใหญ่ไม่ได้ และ ใน SQLite นั้น การใช้ร่วมกัน จะทำให้มีการ lock file ( คือ ขณะที่คนหนึ่งกำลังเปลี่ยนข้อมูล มันจะ lock file ไม่ให้คนอื่นเข้ามายุ่ง) ระบบนี้ ทั้งใน windows & Linux ยังมีปัญหาอยู่ ( มีBugs) อันนี้ เป็นปัญหาของระบบปฎิบัติการ ไม่ใช่ของ SQLite เอง ฉนั้นกฎง่ายๆ ก็คือว่า หากมีการใช้ ร่วมกันแยะ ผ่านระบบเครือข่าย ก็ไม่ควรใช้ SQlite ( ในความเห็นของผู้แปล อย่าง ระบบห้องสมุด ที่ ครู1/3 กำลังทำอยู่ คิดว่า SQLite จัดการได้สบายๆ เพราะ ห้องสมุด คงไม่ยุ่งขนาดมี คนใช้มาก หรือ ใช้พร้อมกันแยะหรือบ่อย)

High-Volume Websites : อย่างที่ว่ามาข้างบน หากต้องการใช้ SQLite เป็น ตัวจัดการ ในเวป มันก็ทำงานได้ แต่หากเวป มันยุ่งมากจนคิดว่า ต้องแบ่ง เครื่องออก ให้ช่วยทำงาน แยกกัน เช่นนี้ ก็ควรต้องใช้ ระบบฐานข้อมูลตัวโต

ปัญหา การแบ่งงานให้เครืองแยกกันทำนั้น ไม่ใช้ ปัญหาของ backend แต่ปัญหาที่จะเกิดมาจาก การออกแบบตัวโปรแกรมที่จะทำงาน เช่น จะส่งรายชื่อ ของลูกค้า ไปยัง web browser อาจจะส่งไปได้ทีละ 50 ชื่อสบายๆ แต่ในราย 10,000 ชื่อ เราก็อาจจะต้องเขียนโปรแกรม แบ่งเป็นหน้าๆ ( 1,2,......) และ/หรือ ( หน้าที่แล้ว/หน้าต่อไป) นี่คือส่วนที่จะต้องมีการออกแบบ เขียนโปรแกรม ขึ้นมา ฉนั้นจะเห็นว่า มันไม่ได้เกี่ยวกับตัวบริหารจัดการข้อมูล แต่มันเป็นเรื่องการเขียนโปรแกรมขึ้นมาใช้ สรุปก็คือว่า กว่าที่ SQLite จะจัดการไม่ได้นั้น ปัญหามันจะมาจากการเขียนโปรแกรมใช้ มากกว่า ข้อจำกัดในการใช้ SQLite
High Concurrency: SQLite ใช้ วิธีlock ตอน เขียน/อ่าน database file ฉนั้น หากใครกำลังอ่านข้อมูลอยู่ มันจะกัน ไม่ให้คนอื่นเข้าเขียนข้อมูลเข้า ก็เช่นกัน หากใครกำลังเขียนข้อมูลเข้า มันจะกันไม่ให้คนอื่นอ่านข้อมูลออกมา โดยทั่วไป อันนี้ไม่ใช่ปัญหา เพราะมันทำได้เร็ว ( ไม่กี่ milliseconds) แต่ในรายมีคนใช้แยะๆ ก็ต้องหาตัวอื่นมาใช้แทน SQLite