ในแง่ของการเขียน Code บน JavaScript หรือภาษาโปรแกรมส่วนใหญ่ “แทบจะไม่ต่างกันเลย” ครับ เพราะความแตกต่างจริง ๆ มันไปอยู่ที่ Database Engine มากกว่า
เพื่อให้เห็นภาพชัดเจน ผมขอแบ่งแยกส่วนที่เป็น Code กับส่วนที่คุยกับ Database ออกจากกันดังนี้ครับ
ในฝั่ง JavaScript
ในภาษา JavaScript เราไม่มีสิ่งที่เรียกว่า JSONB ครับ เรามีแค่ Object และ JSON String
- ตอนรับส่งข้อมูล: คุณยังคงใช้
JSON.parse ()และJSON.stringify ()เหมือนเดิม - ตอนเขียน Logic: คุณก็เรียกใช้งานตัวแปรเป็น Object ปกติ เช่น
user.profile.age
ดังนั้น ไม่ว่า Database ปลายทางจะเป็น JSON หรือ JSONB ตัวแปรใน JavaScript ของคุณก็ยังหน้าตาเหมือนเดิมครับ
ในฝั่งการติดต่อ Database
ตรงนี้คือจุดที่ “ต่างกัน” ครับ หากคุณเขียน Query เองโดยไม่ผ่าน ORM คุณต้องใช้ Operator ที่ต่างกันเพื่อให้ได้ประสิทธิภาพสูงสุด
ตัวอย่างใน PostgreSQL
การดึงข้อมูลธรรมดา
-- ทั้ง JSON และ JSONB ใช้แบบนี้ได้
SELECT data->>'name' FROM users;
การค้นหา ที่ JSONB ทำได้ดีกว่า
หากใช้ JSONB คุณจะสามารถใช้ Operator พิเศษอย่าง @> ซึ่งทำงานร่วมกับ GIN Index ทำให้ค้นหาข้อมูลมหาศาลได้ในเสี้ยววินาที
-- ค้นหาแถวที่ใน column 'data' มี key 'role' เป็น 'admin'
-- (JSONB จะเร็วมากถ้าทำ Index ไว้ ส่วน JSON ปกติจะช้ากว่าเพราะต้องไล่อ่านทุกบรรทัด) SELECT * FROM users WHERE data @> '{"role": "admin"}';
เมื่อใช้ ORM
หากคุณใช้ Library เหล่านี้ การเขียน Code แทบจะเหมือนกัน 100% ครับ
- ตอนนิยาม Schema: คุณแค่ระบุ Type ของ Column เป็น
Json - ตอนสั่ง Save
// Code เหมือนเดิม ไม่ว่า DB จะเป็น JSON หรือ JSONB await prisma.user.create ({ data: { profile: { age: 25, city: "Bangkok" } } }) ;
สรุป: ต้องเปลี่ยนวิธีเขียน Code ไหม ?
- ถ้าเขียน Logic ทั่วไป: ไม่ต้องเปลี่ยน เขียนเป็น Object ปกติได้เลย
- ถ้าเขียน SQL Query เอง: ต้องศึกษา Operator เพิ่ม เพื่อดึงพลังของ JSONB ออกมาใช้
- การจัดการข้อมูล: JSONB จะไม่อนุญาตให้มี Key ซ้ำกัน และไม่เรียงลำดับ Key ให้
คำแนะนำ: ถ้าเลือกได้ ให้ใช้ JSONB เสมอครับ เพราะในฝั่ง Programming เขียนเหมือนกัน แต่ในฝั่ง Performance และความยืดหยุ่น JSONB กินขาดครับ
อ่านเพิ่มเติม