🛑 1. The Problem First: "พยายามตอกตะปูด้วยเลื่อย" (The Wrong Tool Choice)
ลองนึกถึงวันที่คุณต้องเลือกฐานข้อมูลสำหรับโปรเจกต์ใหม่:
// ❌ Naive Approach: ใช้ MongoDB กับระบบบัญชีที่ต้อง JOIN ข้อมูลมหาศาล
// คอลเลกชัน Orders: [{ userId: 1, items: [...] }]
// คอลเลกชัน Users: [{ id: 1, name: "Joe" }]
// 🌋 พัง! เมื่อคุณต้องการดูว่า "User คนนี้มียอดซื้อรวมเท่าไหร่พร้อมชื่อที่อยู่"
// คุณต้องยิง Query ไปกลับหลายรอบ หรือเขียน Aggregation ที่ซับซ้อนจนอ่านไม่ออก
ปัญหา: การเลือก Database ตาม "ความชอบ" หรือ "กระแส" โดยไม่ดูเนื้องาน คือจุดเริ่มต้นของปัญหา Performance และความปวดหัวในการเขียนโค้ด ถ้าข้อมูลของคุณมีความสัมพันธ์ซับซ้อนแต่คุณเลือก NoSQL หรือถ้าข้อมูลคุณเปลี่ยนตลอดเวลาแต่คุณเลือก SQL ที่เข้มงวดเกินไป คุณกำลังสร้างหนี้ทางเทคนิคตั้งแต่วันแรกครับ
💡 2. Real-Life Analogy: ห้องสมุดที่มีระเบียบ vs กระเป๋าโดราเอมอน
- PostgreSQL (SQL): เหมือน "ห้องสมุดเขต". ทุกอย่างมีชั้นวางชัดเจน (Schema) หนังสือประวัติศาสตร์ห้ามวางปนกับนิยาย (Data Integrity) ถ้าคุณจะเพิ่มหมวดใหม่ คุณต้องทำเรื่องขออนุญาต (Migration) แต่ข้อดีคือคุณหาหนังสือเจอได้เป๊ะและเชื่อมโยงข้อมูลกันง่ายมาก
- MongoDB (NoSQL): เหมือน "กระเป๋าโดราเอมอน". คุณอยากใส่อะไรเข้าไปก็ได้! รูปภาพ, ข้อความ, วิดีโอ (Flexible Schema) ไม่ต้องบอกใครล่วงหน้า เหมาะสำหรับการเก็บของที่หลากหลายและต้องการความไวในการโยนของลงไป
- Supabase: เหมือน "ห้องสมุดสำเร็จรูปพร้อมบรรณารักษ์ส่วนตัว". คุณได้พลังของ PostgreSQL แต่ไม่ต้องเหนื่อยคุมเอง มีคนช่วยจัดการเรื่องสมาชิก (Auth) และการยืม-คืน (Real-time API) ให้เสร็จสรรพ
🚀 3. Execution Journey: ขั้นตอนการเลือกรากฐาน
Senior จะไม่เลือกจนกว่าจะเห็น "หน้าตาของข้อมูล"
🛠 Step-by-step:
- Analyze Data Shape: ข้อมูลมีความสัมพันธ์ (Relationship) แข็งแรงไหม? หรือเป็นแค่กล่องเก็บของ (Document)?
- Schema Lockdown: ถ้าเป็นเรื่องเงินหรือความถูกต้อง 100% ให้ใช้ PostgreSQL
- Speed of Dev: ถ้าต้องการความไวหรือทำ Prototype ที่ขยับ Schema บ่อยๆ MongoDB คือเพื่อนที่ดี
- Cloud Infrastructure: ใช้ Supabase เพื่อลดภาระการตั้งค่า Server และเน้นไปที่การเขียน Business Logic
// ✅ Best Practice: การดักจับความผิดพลาดในระบบ SQL
// ในระบบ PostgreSQL เราสามารถป้องกัน "ข้อมูลกำพร้า" ได้ที่ระดับ DB เลย
ALTER TABLE orders
ADD CONSTRAINT fk_user
FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE;
// 🛠 มั่นใจได้ 100% ว่าถ้าลบ User ข้อมูล Order จะไม่ค้างเป็นขยะ
🪤 4. The Junior Trap: โรค "Schema-less คือไม่ต้องวางแผน"
จูเนียร์มักจะชอบ NoSQL เพราะ "ไม่ต้องเขียน Schema" แต่อาจกลายเป็นฝันร้ายตอนดึงข้อมูล:
// ❌ Junior Trap: ใส่ข้อมูลมั่วลงใน MongoDB
db.collection("users").insert({ name: "Joe" });
db.collection("users").insert({ full_name: "Jane", age: 25 });
// 🌋 พัง! ตอนเขียน Frontend คุณจะงงว่าสรุปต้องเช็ค 'name' หรือ 'full_name' กันแน่?
// กลายเป็นว่าต้องไปเขียน IF-ELSE เช็คข้อมูลเน่าๆ ในโค้ดแทนที่จะแก้ที่ต้นทาง
ระวัง: Schema-less ไม่ได้แปลว่า No Schema แต่หมายความว่า Schema ย้ายไปอยู่ที่ "Application Level" แทน ซึ่งถ้าคุมไม่ดี โค้ดคุณจะรกมาก ✅ การแก้ไข: แม้จะเป็น NoSQL ก็ควรใช้เครื่องมืออย่าง Mongoose เพื่อกำหนด Schema ในโค้ดให้ชัดเจนครับ
⚖️ 5. The Why Matrix: PostgreSQL vs MongoDB
| หัวข้อ | PostgreSQL (SQL) | MongoDB (NoSQL) |
|---|---|---|
| ความยืดหยุ่น | 🐢 ต่ำ (ต้องทำ Migration) | 🚀 สูงมาก (ใส่อะไรก็ได้) |
| ความถูกต้อง (ACID) | ⚡⚡⚡ สูงสุด (ปลอดภัย) | ปานกลาง (เน้นความเร็ว) |
| การ JOIN ข้อมูล | ⚡⚡⚡ เทพ (SQL Join แรงมาก) | ทำได้ยากและช้า (Lookup) |
| การขยายตัว (Scale) | แนวดิ่ง (เพิ่ม RAM/CPU) | แนวราบ (เพิ่มจำนวนเครื่องง่ายกว่า) |
| เหมาะกับ | E-commerce, Fintech, SaaS ทั่วไป | Logging, Chat, Real-time Feeds |
🎓 6. Senior Mindset Summary
การเป็น Senior คือการมองว่า "Database ไม่ใช่แค่ที่เก็บของ แต่คือตัวกำหนดความยากง่ายของการเขียนโปรแกรมในอีก 1 ปีข้างหน้า". อย่าเลือกเพราะความเท่ แต่เลือกเพราะมันสามารถดูแลรักษา (Maintain) ได้ง่ายที่สุดสำหรับความต้องการของธุรกิจครับ!
Mission Accomplished
You've reached the end of this module. Time to apply these senior mindsets to your real-world projects!