จะว่าไป ฐานข้อมูลแบบปกติ (RDBMS) กับ NOSQL ก็เหมือนกับเทียบกลศาสตร์ดั้งเดิมกับกลศาสตร์ควันตัม คือมันเหมาะสมกับงานคนละประเภทกัน

ฐานข้อมูลแบบปกติ (RDBMS) เรียกว่าตอบโจทย์งานธุรกิจทั่วไปได้ตั้งแต่เล็กไปถึงใหญ่ได้ค่อนข้างดี, มีกลไกการรับประกันข้อมูลว่าจะมี integrity ดี (ACID), เทคโนโลยีมีการพัฒนา engine อย่างต่อเนื่องกว่าสามสิบปี ตำราเยอะมาก, มีลูกเล่นสารพัดเพื่อเพิ่มสมรรถนะการทำงาน, เครื่องมือเครื่องไม้ช่วยงานหลากหลายสารพัดหลากยี่ห้อ

แต่มีข้อจุดอ่อนตรงที่

• มีความยืดหยุ่นต่ำ: ข้อมูลชนิดหนึ่งๆ จะมีโครงสร้างข้อมูล (schema) เหมือนกันทั้งหมด (นึกภาพข้อมูลถูกยัดลงในตารางแบบกริด) ซึ่งเหมาะกับงานที่โมเดลธุรกิจชัดเจนแล้ว มีการเปลี่ยนแปลง schema/data model ไม่บ่อยนัก แต่ซึ่งในงานที่ต้องการความคล่องตัวสูงมากๆ เช่น การวิเคราะห์ออกแบบสร้าง data model ของข้อมูลที่ไม่มีโครงสร้าง (เช่น เนื้อหาอีเมล์, ฟีด, กระทู้) ปริมาณมหาศาลและมีข้อมูลเพิ่มขึ้นเรื่อยๆ ก็ออกจะลำบากอยู่

• scalability: ฐานข้อมูลปกติถูกออกแบบสำหรับงานรวมศูนย์ตั้งแต่ต้น, สามารถทำ serialize ได้ ข้อดีคือ สถานะของข้อมูลทุกตาราง ทั้งระบบ มีความสมบูรณ์ สอดคล้องกันอยู่ตลอดเวลา (integrity) ซึ่งเหมาะกับเรื่องเงินๆ ทองๆ แต่เมื่อระบบมีขนาดใหญ่มากขึ้น จนกระทั่งขยายไปแบบคลัสเตอร์ก็ไม่ได้ประสิทธิภาพมากพอ (ยังมีข้อจำกัดคือ เครื่องต้องมีการซิงค์กัน โดยเฉพาะเวลาอัพเดตข้อมูล ทำให้ประสิทธิภาพที่เพิ่มขึ้นในช่วงหลังๆ จะลดลง) แต่ NOSQL ส่วนใหญ่มาแบบ distributed ตั้งแต่ต้น

ส่วน NOSQL เองก็ไม่ใช่ว่าจะมีข้อเสีย ด้วยความที่เป็น emerging technology ทำให้มีข้อเสีย

• เครื่องมือเครื่องไม้ยังไม่เยอะนัก (เมื่อเทียบกับ RDBMS) โดยเฉพาะ GUI tool
• ด้วยความที่เทคโนโลยีใหม่ เกิดขึ้นไม่นานนัก ความรู้,เครื่องมือ,ภาษาเปลี่ยนแปลง หรือตกยุค อย่างรวดเร็ว เรียกว่าถ้าเลือกเครื่องมือผิดก็ซวยไป (แต่หลังๆนี่อาจะดีขึ้นแล้ว)
• หาคนเรียนรู้หรือชำนาญได้ยาก การหาคนมารับช่วงต่อก็ท้าทายกว่า
• การเชื่อมต่อกับระบบ RDBMS ไม่ง่ายดายนัก: คืออย่างไรก็ต้องบอกว่า noSQL ไม่ใช่ทุกอย่าง หลายครั้งเวลาที่ต้องเชื่อมต่อ รับ/ส่ง กับระบบที่มีอยู่ ก็จะปวดหัวหน่อย

สองอันสุดท้ายอาจจะทำให้บริษัทคิดจะใช้ NOSQL ก็ต้องคิดมากหน่อย

ส่วนใหญ่ที่เหมาะกับงาน NOSQL จะเป็นพวกระบบขนาดใหญ่มากๆ หรือระบบที่ parallelism สูงมากๆ หรือ เน้นที่การวิเคราะห์ข้อมูลปริมาณมหาศาล, ไม่ค่อยเห็นใช้กับงานที่เกี่ยวกับการบันทึกข้อมูล เงินๆ ทองๆ โดยตรง (ลงบัญชี, ระบบซื้อมาขายไป)

ที่ผมนึกออก นอกจาก SQL แล้วก็น่าจะมี PL/SQL ของ Oracle แล้วก็ OpenEdge ABL (หรือ Progress4GL)

PL/SQL มีลักษณะเหมือนเป็นส่วนขยายของ SQL ผมไม่ค่อยมีความรู้เท่าไหร่ แต่ว่าก็เห็นมีคนใช้กันเยอะ ลองค้น ๆ ดูก็น่าจะเจอกันได้ไม่ยาก

OpenEdge Advanced Business Language นี่ผมไม่ค่อยเห็นคนใช้กันเท่าไหร่ (บ้านเรามี DST กับ Progress Software แล้วก็ Toyota มั้ง ? ได้ยินมา) โครงสร้างภาษาใกล้เคียงกับพวก Procedural มากกว่า SQL อย่างสมมติผมต้องการจะ query เอา account กับ balance ขึั้นมาจาก table Account-Balance ใน SQL ก็อาจจะเขียนแบบ ...

SELECT account, balance
FROM Account-Balance.

ใน ABL จะเขียนว่า

FOR EACH Account-Balance NO-LOCK:
    DISPLAY account, balance.
END.

ส่วนตัวผมเป็นคนไม่ชอบ Database เวลาเขียน query แล้วจะหงุดหงิด เพราะภาษามันโบราณมากและไม่ค่อยมีการอัพเดตให้ทัดเทียมกับภาษาพวก General Purpose ทั่ว ๆ ไป (เชื่อไหมว่าไอ้ภาษาข้างบนที่ว่ามาเป็น Case-Insensitive หมดเลย) ผมคิดว่าถ้าจะพัฒนาระบบจริง ๆ จัง ๆ ในพศ.นี้ก็ไม่ควรเขียน Business Logic ในภาษากลุ่มนี้ครับ ไล่แล้วปวดกะบาลมาก ให้ตาย (ประสพการณ์ตรง 555)

ปล. ผมเกลียดฐานข้อมูลครับ ถึงตอนเรียนจะได้ A มาก็เหอะ 555