Databases Versioning

มีปัญหาเรื่อง Database Version ก็เลยไปหาอ่านว่าเค้าแก้ปัญหากันยังไง แล้วพบกับ Blog นี้ http://odetocode.com/blogs/scott/archive/2008/01/30/three-rules-for-database-work.aspx ช่วยได้เยอะมาก เลยเอามาเขียนสรุปไว้ กันลืม

1. อย่าใช้ Database ร่วมกันในขณะพัฒนา

เพราะความสะดวกสบายในการใช้งาน Database ร่วมกัน ทำให้หลายๆ ทีม Point Connection ไปที่ Database Server ที่เดียวกัน ก้อนเดียวกัน ซึ่งทุกๆ คนก็จะสามารถเปลี่ยนแปลงข้อมูล หรือโครงสร้างฐานข้อมูลได้ ซึ่งมีผลทันที และส่งผลกระทบกับ Developer คนอื่นๆ ทันทีด้วย แน่นอนว่าจะเกิดปัญหาการแก้ข้อมูลชนกัน หรือซ้อนทับกัน การเลิกใช้ Database ร่วมกันในขณะพัฒนาระบบ จะทำให้ลดปัญหาเรื่องเสียเวลา และลดบั๊กที่เกี่ยวข้องกับ Database ได้

2. ใช้โครงสร้างฐานข้อมูลจากที่มาแหล่งเดียวกันเสมอ

สมมุติว่ามีเหตุการณ์นี้เกิดขึ้น
Developer 1 : เฮ้ ชั้นเขียนโปรแกรมเสร็จแล้ว จะ push app ขึ้นไป ทดสอบ เราจะใช้ Database จากเครื่องใครดี ของแจ๊ค หรือของจอนห์
Developer 2 : อืมมมมมมมม จำไม่ได้แล้วหว่ะ ว่าของใครอัพเดทกว่ากัน
Developer 1 : ฉิบหาย!!

ทุกคนควรรู้ว่า โครงสร้างฐานข้อมูลอันไหน เป็นตัวจริง และเป็นปัจจุบันที่สุด การเอา Tools พวก Database Versioning มาใช้ จะช่วยเรื่องนี้ได้

3. ทำ Database version เสมอ

มีหลายวิธีในการทำ Database version เป้าหมายที่แท้จริงของการทำเรื่องพวกนี้คือการบันทึกและเผยแพร่การเปลี่ยนแปลงที่เกิดขึ้นจากการพัฒนาระบบไปให้คนอื่นในทีม เป้าหมายรองลงมาคือ เราสามารถสร้าง Database จากโครงสร้าง ที่เกิดในช่วงเวลาไหนก็ได้ (ถ้าเรา tracking ไว้) ประโยชน์ก็คือ กรณีที่เราส่งระบบให้ลูกค้าไปแล้ว และพบ Bug ใน version 0.3.2 เราก็สามารถติดตั้ง Apps และ Database ให้ตรงกันกับของลูกค้าเพื่อแก้ใข Bug ได้


เครื่องมือ

เครื่องมือที่ง่ายและเหมาะในการทำ Databases Versioning ที่ไปเจอมาคือ dbv (http://dbv.vizuina.com/) ลองใช้แล้วก็ช่วยแก้ปัญหาได้ และไม่ซับซ้อน ไม่ต้องมี Learning Curve

สรุป Flow เป็น Sequence Diagram ได้ตามนี้เลย