Back to: DBA Never Out
RDBMS คืออะไร ทำงานอย่างไร
ก่อนจะติดตั้งอะไรสักตัวหรือพิมพ์คำสั่ง SQL บรรทัดแรก เราต้องเข้าใจก่อนว่ากำลังคุยกับอะไรอยู่ RDBMS ไม่ใช่แค่ “ที่เก็บข้อมูล” แต่เป็นระบบทั้งชุดที่ตัดสินใจแทนเราว่าข้อมูลจะถูกเก็บยังไง ค้นยังไง และรับประกันความถูกต้องได้ยังไง — เข้าใจตอนนี้ให้แน่น เพราะทุกบทถัดไปยืนอยู่บนความเข้าใจนี้ทั้งหมด
RDBMS ย่อมาจาก Relational Database Management System คือซอฟต์แวร์ที่จัดการข้อมูลในรูปแบบ “ตาราง” (table) ที่มีแถว (row) และคอลัมน์ (column) คล้ายสเปรดชีต แต่ต่างกันตรงที่ตารางเหล่านี้ เชื่อมโยงกันได้ ผ่านค่าที่อ้างอิงถึงกัน เช่น ตาราง “คำสั่งซื้อ” อ้างอิงไปยังตาราง “ลูกค้า” ด้วยรหัสลูกค้า นี่คือที่มาของคำว่า “Relational” — ความสัมพันธ์ระหว่างตารางนี่แหละคือหัวใจของทั้งระบบ
สิ่งที่ทำให้ RDBMS ต่างจากการเก็บข้อมูลแบบไฟล์ธรรมดา คือมันมีกฎตายตัวที่บังคับให้ข้อมูลถูกต้องและสอดคล้องกันเสมอ เช่น จะไม่มีทางมีคำสั่งซื้อที่อ้างถึงลูกค้าที่ไม่มีอยู่จริงในระบบ — กฎพวกนี้เรียกรวม ๆ ว่า referential integrity ซึ่งเราจะเจาะลึกในบทที่ 3
เวลาพิมพ์คำสั่ง SQL หนึ่งบรรทัด มันไม่ได้วิ่งไปหาข้อมูลตรง ๆ แต่ผ่านหลายชั้นในตัว RDBMS เอง:
- Query Parser — ตรวจว่าคำสั่งที่พิมพ์ถูกไวยากรณ์ SQL ไหม
- Query Optimizer — วางแผนว่าจะไปดึงข้อมูลด้วยวิธีไหนถึงจะเร็วที่สุด (จะพูดละเอียดในบทที่ 4)
- Storage Engine — ตัวจริงที่อ่าน/เขียนข้อมูลลงดิสก์ และจัดการ index
- Transaction Manager — คุมให้การเปลี่ยนแปลงข้อมูลสำเร็จทั้งหมดหรือไม่สำเร็จเลย (จะพูดละเอียดในบทที่ 7)
DBA ที่เก่งไม่จำเป็นต้องรู้ทุกบรรทัดของโค้ดเหล่านี้ แต่ต้องรู้ว่าแต่ละชั้นทำหน้าที่อะไร เพราะเวลาระบบช้าหรือมีปัญหา คำถามแรกที่ต้องถามตัวเองคือ “ปัญหาอยู่ชั้นไหน”
ลองนึกภาพร้านค้าออนไลน์ร้านหนึ่ง ถ้าเก็บทุกอย่างไว้ในตารางเดียว เช่น แถวหนึ่งมีทั้งชื่อลูกค้า ที่อยู่ สินค้าที่ซื้อ และราคา — พอลูกค้าคนเดิมสั่งซื้อรอบสอง ก็ต้องพิมพ์ชื่อกับที่อยู่ซ้ำอีกรอบ ถ้าที่อยู่เปลี่ยน ก็ต้องไล่แก้ทุกแถว นี่คือปัญหาที่ RDBMS แก้ตั้งแต่ต้นทาง
วิธีที่ถูกต้องคือแยกเป็นตาราง customers (เก็บข้อมูลลูกค้าครั้งเดียว), products (เก็บสินค้า), และ orders (เก็บแค่ว่าใครซื้ออะไร โดยอ้างอิง id ไปยังอีกสองตาราง) เวลาลูกค้าเปลี่ยนที่อยู่ แก้ที่เดียวในตาราง customers จบ ทุกคำสั่งซื้อเก่าก็ยังอ้างอิงถูกต้องอัตโนมัติ — นี่คือเหตุผลที่บทที่ 3 เราจะเรียนเรื่อง normalization กันอย่างจริงจัง เพราะโครงสร้างแบบนี้ไม่ได้เกิดขึ้นเอง ต้องออกแบบ
| ประเด็น | RDBMS (เช่น PostgreSQL) | NoSQL (เช่น MongoDB) |
|---|---|---|
| โครงสร้างข้อมูล | ตาราง แถว คอลัมน์ ตายตัว (schema) | เอกสาร (document) ยืดหยุ่นกว่า |
| ความสัมพันธ์ | เชื่อมด้วย JOIN ตามค่าที่อ้างอิงกัน | มักฝังข้อมูลไว้ในเอกสารเดียวกัน |
| ความสอดคล้อง | เข้มงวด (ACID) เหมาะกับข้อมูลการเงิน | ยืดหยุ่นกว่า เน้นขยายระบบง่าย |
| ใช้เมื่อไหร่ | ข้อมูลมีโครงสร้างชัด ต้องแม่นยำสูง | ข้อมูลเปลี่ยนรูปแบบบ่อย ต้องการ scale เร็ว |
ในคอร์สนี้เราจะใช้ตัวอย่างจาก PostgreSQL และ MySQL เป็นหลัก เพราะเป็น open-source ที่ใช้งานจริงในอุตสาหกรรมมากที่สุด แต่หลักการที่เรียนใช้ได้กับทุกเจ้า เพราะพื้นฐาน relational model เหมือนกันหมด ต่างกันแค่รายละเอียดปลีกย่อยและ syntax บางส่วน
ยอดนิยมที่สุดสำหรับเว็บแอป ติดตั้งง่าย ชุมชนใหญ่ ใช้กันแพร่หลายในสาย WordPress/PHP
ฟีเจอร์ครบและมาตรฐานสูงกว่า เหมาะกับระบบที่ซับซ้อน และเป็นที่นิยมในทีม data-heavy
ของ Microsoft พบมากในองค์กรที่ใช้ ecosystem ของ Microsoft อยู่แล้ว
แข็งแกร่งระดับองค์กรใหญ่ พบบ่อยในธนาคารและระบบ legacy ขนาดใหญ่
อย่าไปกังวลว่าต้องเลือก “เจ้าไหนดีที่สุด” ตั้งแต่ตอนนี้ เพราะ DBA มืออาชีพส่วนใหญ่ทำงานข้ามหลายเอนจินได้ในอาชีพเดียว สิ่งที่ต้องแม่นคือหลักการ relational model ที่ใช้ร่วมกันได้ทุกที่ ส่วนรายละเอียดปลีกย่อยของแต่ละเอนจินค่อยไปเรียนรู้เพิ่มตอนเจองานจริง
ลองฝึกคิดแบบ RDBMS กับระบบใกล้ตัวครับ:
- เลือกระบบที่คุณคุ้นเคย (เช่น ระบบร้านค้า ระบบจองคิว หรือระบบสมาชิกฟิตเนส) แล้วแตกออกมาเป็นตารางหลักอย่างน้อย 3 ตาราง
- ระบุว่าแต่ละตารางควรมีคอลัมน์อะไรบ้าง อย่างน้อยตารางละ 3 คอลัมน์
- บอกว่าตารางไหนควรเชื่อมกับตารางไหน ผ่านคอลัมน์อะไร (เช่น “orders เชื่อมกับ customers ผ่าน customer_id”)
💾 บันทึกอัตโนมัติในเบราว์เซอร์นี้เท่านั้น