ทำไม Database ถึงต้องมี Version Control?

ปัญหาคลาสสิกที่ Dev ทุกคนต้องเคยเจอ:

1. Dev A: เพิ่ม column phone_number ในตาราง User แล้ว commit code ขึ้น Git
2. Dev B: Pull code มา run -> App พัง! เพราะ Database เครื่อง Dev B ไม่มี column นั้น
3. Production: ถึงวัน Deploy ลืมรัน Script SQL เพิ่ม column -> ลูกค้าร้องเรียน เพราะระบบ Error

การแก้ปัญหาด้วยการแปะไฟล์ .sql ไว้ในแชทกลุ่ม หรือเขียนใส่ Text File บอก Admin ว่า "อย่าลืมรันอันนี้นะ" เป็นวิธีที่มีความเสี่ยงสูงมากครับ

ทางออก: ให้ Flyway จัดการแทน (Database Migration)

Flyway คือเครื่องมือที่ทำหน้าที่เป็น "Git สำหรับ Database" หลักการทำงานง่ายมาก:

1. เราเก็บคำสั่ง SQL (Create Table, Alter Table) ไว้ในไฟล์ที่เป็นลำดับขั้น (V1, V2, V3...)
2. เมื่อ Spring Boot เริ่มทำงาน (Start App) มันจะเช็คให้เองว่า "ตอนนี้ Database อยู่เวอร์ชันไหนแล้ว?"
3. ถ้ามีไฟล์เวอร์ชันใหม่ที่ยังไม่เคยรัน มันจะรันให้ อัตโนมัติ

วิธีใช้งานใน Spring Boot

ความดีงามคือ Spring Boot รองรับ Flyway แบบ First-class citizen แค่ทำตามนี้:

1. เพิ่ม Dependency (ใส่แค่ flyway-core และ Driver Database ที่คุณใช้อยู่)

<dependency>
    <groupId>org.flywaydb</groupId>
    <artifactId>flyway-core</artifactId>
</dependency>

2. สร้างไฟล์ SQL ตามมาตรฐาน สร้างโฟลเดอร์ src/main/resources/db/migration แล้ววางไฟล์ SQL โดยตั้งชื่อตามกฎ: V{version}__{description}.sql (สังเกตเครื่องหมาย __ ขีดล่าง 2 ตัว)

• V1__init_schema.sql: สร้างตารางเริ่มต้น

CREATE TABLE users (
    id INT PRIMARY KEY,
    username VARCHAR(100)
);

• V2__add_status_column.sql: วันต่อมา อยากเพิ่ม Column

ALTER TABLE users ADD COLUMN status VARCHAR(20);

3. กด Run App! จบครับ! ทันทีที่คุณ Start Spring Boot:

• มันจะสร้างตาราง flyway_schema_history เพื่อจดบันทึก
• มันจะเห็นว่า V1 และ V2 ยังไม่เคยรัน
• มันจะรัน SQL เหล่านั้นให้ และอัปเดตสถานะว่า "Database นี้เป็น Version 2 แล้วนะ"

ความแตกต่างของผลลัพธ์ที่ได้

1. Consistency (ความเท่าเทียม): ไม่ว่าจะเป็นเครื่อง Dev, เครื่อง Test หรือ Production ทุกเครื่องจะมีโครงสร้าง Database เหมือนกันเป๊ะ 100% ตาม Code ที่ Pull มา
2. Zero Manual Work: ไม่ต้องมานั่งจำว่า "รัน Script นี้หรือยัง?" หรือต้อง Remote เข้า Production ไปรัน SQL เอง (ซึ่งอันตรายมาก)
3. CI/CD Integration: ระบบนี้ทำงานอัตโนมัติใน Pipeline ได้เลย แค่ Deploy Code ปุ๊บ Database ก็จะถูก Migrate ปั๊บ

ข้อควรระวัง (Do & Don't)

• ห้ามแก้ไขไฟล์เก่า: ถ้าไฟล์ V1 ถูกรันไปแล้ว ห้าม กลับไปแก้เนื้อหาในไฟล์นั้นเด็ดขาด (เพราะ Checksum จะเปลี่ยน และ Flyway จะ Error ทันทีเพื่อเตือนความปลอดภัย)
• ต้องสร้างไฟล์ใหม่เสมอ: ถ้าต้องการแก้ตาราง ให้สร้างไฟล์ V3 เพื่อ ALTER TABLE แทนการแก้ไฟล์เดิมครับ

บทสรุป

การใช้ Flyway ช่วยเปลี่ยน Database Management จากงาน Manual ที่เสี่ยงต่อความผิดพลาด ให้กลายเป็น Automated Process ที่ตรวจสอบได้ ย้อนดูประวัติได้ และไปพร้อมกับ Source Code ของเราครับ