ความท้าทายที่มีมายาวนานในการแปลงตารางฐานข้อมูลแบบเรียบเป็นโครงสร้างแบบลำดับชั้นสำหรับส่วนติดต่อผู้ใช้ได้จุดประกายการพิจารณาใหม่ในชุมชนนักพัฒนา ปัญหานี้เรียกว่า object-relational mismatch เกิดขึ้นเมื่อแอปพลิเคชันต้องแสดงความสัมพันธ์ที่ซับซ้อนในลำดับชั้นภาพที่แตกต่างกันขึ้นอยู่กับงานที่ต้องทำ
ข้อจำกัดของ SQL แบบดั้งเดิมสร้างปัญหาให้กับการพัฒนา
เป็นเวลาหลายทศวรรษที่นักพัฒนาต้องต่อสู้กับความไม่สามารถของ SQL ในการสร้างผลลัพธ์ที่มีโครงสร้างโดยตรง เมื่อสร้างสิ่งง่ายๆ เช่นหน้าภาพยนตร์ที่แสดงผู้กำกับ นักแสดง และประเภทภาพยนตร์ SQL แบบดั้งเดิมบังคับให้นักพัฒนาต้องทำคิวรีฐานข้อมูลหลายครั้ง คิวรีแต่ละครั้งจะคืนค่าข้อมูลแบบเรียบที่ต้องนำมาประกอบใหม่ในโค้ดแอปพลิเคชัน ทำให้เกิดความซับซ้อนที่ไม่จำเป็นและคอขวดด้านประสิทธิภาพ
ชุมชนได้รับรู้จุดเจ็บปวดนี้มานาน การเชื่อมต่อเครือข่ายหลายครั้งกลายเป็นสิ่งจำเป็น และเครื่องมือ Object-Relational Mapping (ORM) ได้ถือกำเนิดขึ้นเป็นทางแก้ไข อย่างไรก็ตาม เครื่องมือเหล่านี้มักสร้างปัญหาของตัวเอง รวมถึงการโหลดข้อมูลที่ไม่สม่ำเสมอและปัญหาการผูกมัดกับภาษาเฉพาะ
แนวทางแบบดั้งเดิมเทียบกับ SQL สมัยใหม่
| ด้าน | SQL แบบดั้งเดิม | SQL สมัยใหม่พร้อม JSON |
|---|---|---|
| การเดินทางข้อมูลผ่านเครือข่าย | ต้องใช้หลายคำสั่งค้นหา | สามารถใช้คำสั่งเดียวได้ |
| การประกอบข้อมูล | ต้อง join ด้วยตนเองในโค้ดแอปพลิเคชัน | ฐานข้อมูลจัดการโครงสร้างให้ |
| ประสิทธิภาพ | มีความหน่วงสูงจากการเรียกหลายครั้ง | ลดภาระการส่งข้อมูลผ่านเครือข่าย |
| ความสอดคล้อง | มีความเสี่ยงของข้อมูลจากธุรกรรมที่แตกต่างกัน | รับประกันธุรกรรมเดียว |
ฟีเจอร์ JSON เปลี่ยนความสามารถของฐานข้อมูล
ฐานข้อมูล SQL สมัยใหม่ปัจจุบันรวมฟังก์ชันการรวม JSON ที่สามารถสร้างผลลัพธ์แบบลำดับชั้นในคิวรีเดียว ฟังก์ชัน jsonb_agg() ของ PostgreSQL และฟังก์ชันที่คล้ายกันในฐานข้อมูลอื่นๆ ช่วยให้นักพัฒนาสามารถสร้างโครงสร้างซ้อนที่ซับซ้อนโดยตรงจากข้อมูลเชิงสัมพันธ์ สิ่งนี้ช่วยขจัดความจำเป็นในการทำคิวรีหลายครั้งและลดการสับเปลี่ยนข้อมูลระหว่างชั้นฐานข้อมูลและแอปพลิเคชัน
ชุมชนนักพัฒนาได้ยอมรับความสามารถเหล่านี้อย่างกระตือรือร้น ผู้เชี่ยวชาญด้านฐานข้อมูลกำลังค้นพบว่าตัวดำเนินการลูกศร JSON ใน SQLite และฟีเจอร์ที่คล้ายกันในฐานข้อมูลอื่นๆ ทำให้การทำงานกับข้อมูลกึ่งโครงสร้างเป็นเรื่องปฏิบัติได้มากขึ้น นักพัฒนาบางคนแม้กระทั่งเคลื่อนไปสู่การเก็บทุกอย่างในคอลัมน์ JSON โดยพบว่าความยืดหยุ่นมีน้ำหนักมากกว่าประโยชน์ของการทำ normalization แบบดั้งเดิมสำหรับกรณีการใช้งานบางอย่าง
การรองรับ JSON ในระบบฐานข้อมูลต่างๆ
• PostgreSQL: jsonb_agg(), json_build_object(), LATERAL joins
• SQLite: ตัวดำเนินการลูกศร JSON (->>, ->) พร้อมนิพจน์ที่จัดทำดัชนี
• MariaDB: ฟังก์ชัน JSON_EXTRACT(), JSON_UNQUOTE()
• กรณีการใช้งานทั่วไป: ข้อมูลแบบลำดับชั้น การตอบสนอง API สคีมาที่ยืดหยุ่น
ชุมชนผลักดันให้มีการพัฒนา SQL ที่ดีขึ้น
แม้จะมีการต่อต้านจากผู้ที่ยึดมั่นในแนวคิดเดิมที่โต้แย้งว่าข้อมูลที่มีโครงสร้างไม่ควรอยู่ในฐานข้อมูล นักพัฒนาที่มีแนวคิดปฏิบัติได้นำฟีเจอร์ใหม่เหล่านี้มาใช้อย่างรวดเร็ว การพิจารณานี้เผยให้เห็นความรู้สึกที่เพิ่มขึ้นว่าเครื่องมือควรพัฒนาไปเพื่อตอบสนองความต้องการปัจจุบันมากกว่าการยึดมั่นในหลักการออกแบบที่มีมาหลายทศวรรษ
เมื่อสิ่งใดใน SQL กลายเป็นเรื่องยุ่งยากหรือทำงานได้ยาก ผู้คนมักจะมีแนวโน้มสร้างทางแก้ไขใหม่ทั้งหมดแทนที่จะปรับปรุงสิ่งที่มีอยู่ นักพัฒนาเพียงไม่กี่คนที่ดูเหมือนจะสนใจในการปรับปรุง SQL เอง
การเปลี่ยนแปลงนี้แสดงถึงการเปลี่ยนแปลงพื้นฐานในวิธีที่นักพัฒนาคิดเกี่ยวกับความรับผิดชอบของฐานข้อมูล แทนที่จะปฏิบัติต่อฐานข้อมูลเป็นเพียงชั้นการจัดเก็บ แอปพลิเคชันสมัยใหม่ใช้ประโยชน์จากความสามารถของฐานข้อมูลสำหรับการแปลงข้อมูลและการสร้างโครงสร้าง
ประโยชน์ในทางปฏิบัติขับเคลื่อนการนำมาใช้
การปรับปรุงประสิทธิภาพมีความสำคัญอย่างมาก ทางแก้ไขแบบคิวรีเดียวลดค่าใช้จ่ายเครือข่ายและขจัดความจำเป็นในการถ่ายโอนคีย์การเชื่อมที่ไม่จำเป็นระหว่างฐานข้อมูลและแอปพลิเคชัน ฟีเจอร์ SQL สมัยใหม่เช่น LATERAL joins และ correlated subqueries ให้เครื่องมือที่ทรงพลังสำหรับการหลีกเลี่ยงข้อผิดพลาดทั่วไปเช่นการนับซ้ำในการรวมข้อมูล
ความสามารถเหล่านี้มีค่าเป็นพิเศษสำหรับเว็บแอปพลิเคชันที่การลดการเชื่อมต่อเครือข่ายส่งผลกระทบโดยตรงต่อประสบการณ์ผู้ใช้ ความสามารถในการสร้างโครงสร้างข้อมูลหน้าเว็บที่สมบูรณ์ในการเรียกฐานข้อมูลครั้งเดียวแสดงถึงการปรับปรุงสถาปัตยกรรมที่สำคัญเมื่อเทียบกับแนวทางแบบหลายคิวรีแบบดั้งเดิม
อ้างอิง: SQL needed structure