เข้าใจพื้นฐานฐานข้อมูลสำหรับนักพัฒนา

ฐานข้อมูลเป็นเหมือนกระดูกสันหลังของแอปเกือบทุกตัว แต่ก็เป็นเรื่องที่ developer หลายคนข้ามไป เพราะเชื่อว่า ORM จะจัดการทุกอย่างให้เอง ปัญหาคือเมื่อข้อมูลเยอะขึ้น query ช้าลง หรือต้องแก้ schema ก็จะไม่รู้จะเริ่มตรงไหน บทความนี้สรุปแนวคิดพื้นฐานที่ควรรู้

Table คือหัวใจของทุกอย่าง

ฐานข้อมูล relational เก็บข้อมูลเป็นตาราง แต่ละแถวคือ record ตัวหนึ่ง แต่ละคอลัมน์คือคุณสมบัติของ record นั้น การออกแบบตารางที่ดีคือการถามตัวเองว่า 'entity หนึ่งตัวในระบบนี้มีคุณสมบัติอะไรบ้าง' แล้วแยกตารางตาม entity ไม่ปนกัน

Primary key และ Unique

ทุกตารางควรมี primary key ที่ identify row ได้ชัดเจน ส่วนใหญ่ใช้ auto-increment integer หรือ UUID ข้อดีของ UUID คือสามารถสร้างได้ก่อนส่งไป database ทำให้ client-side optimistic update ทำได้สะดวก ส่วน integer ข้อดีคือเล็กกว่าและ index เร็วกว่า

Relationship: 1-to-many, many-to-many

ความสัมพันธ์ระหว่างตารางมี 3 รูปแบบหลัก — 1-to-1, 1-to-many, many-to-many แต่ที่เจอบ่อยคือ 1-to-many (เช่น User มี Posts หลายอัน) และ many-to-many (Post มี Tags หลายอัน, Tag อยู่ได้หลาย Post)

Many-to-many ต้องสร้างตาราง junction (เช่น post_tags) ที่มี foreign key ไปยังทั้งสองตาราง เป็นจุดที่ developer ใหม่มักสับสน จำง่ายๆ คือ 'ถ้าทั้งสองฝั่งเป็น many ต้องมีตารางกลางเสมอ'

Index: ทำให้ query เร็วขึ้น

Index ทำงานคล้ายสารบัญในหนังสือ ช่วยให้ database หา row ได้เร็วโดยไม่ต้อง scan ทั้งตาราง แต่ index ไม่ฟรี — ทุกครั้งที่ insert/update row database ต้องอัพเดต index ด้วย

กฎง่าย ๆ: index คอลัมน์ที่ใช้ใน WHERE, JOIN และ ORDER BY บ่อย ๆ — ไม่ใช่ทุกคอลัมน์

Composite index

ถ้า query ใช้หลายคอลัมน์พร้อมกัน เช่น WHERE user_id=? AND created_at>? ควรใช้ composite index ครอบทั้งสองคอลัมน์ ลำดับสำคัญ — ให้คอลัมน์ที่เลือกแล้วเหลือ row น้อยที่สุดอยู่ซ้ายสุด

Normalization

Normalization คือการจัด schema ไม่ให้ข้อมูลซ้ำ โดยแยก entity ออกจากกัน จุดประสงค์คือป้องกัน anomaly เวลา update/delete เช่น ถ้าเก็บชื่อ author ใน table posts โดยตรง เวลา author เปลี่ยนชื่อต้อง update หลายแถว

แต่ normalize มากเกินไปทำให้ query ซับซ้อนและช้า สำหรับ web app ทั่วไป 3NF ถือว่าพอดี ไม่ต้องไปถึง BCNF หรือ 4NF

คำแนะนำสุดท้าย

อย่าเพิ่ง optimize ก่อนเจอปัญหา เริ่มจาก schema ที่อ่านง่าย normalize พอเหมาะ ไม่ต้องใส่ index ทุกคอลัมน์ พอข้อมูลโตขึ้นและเจอ query ช้าจริง ๆ ค่อยดู EXPLAIN แล้วปรับ — นี่คือวิธีที่ทำให้ไม่เสียเวลากับการ over-engineer ตั้งแต่วันแรก