การจัดการสคีมาฐานข้อมูลจะเปลี่ยนไปเมื่อทำการกดเวอร์ชั่นใหม่

ในช่วงเวลาของการพัฒนาอย่างหนักสกีมาของฐานข้อมูลจะเปลี่ยนแปลงทั้งอย่างรวดเร็วและต่อเนื่องและเมื่อถึงเวลาที่เราจะทำการสร้างรายสัปดาห์ไปที่รุ่นต่อ ๆ มาสคีมาก็เปลี่ยนไปมากจนตัวเลือกที่เหมาะสมเท่านั้นคือ คัดลอกเวอร์ชันใหม่จากฐานข้อมูล dev ของฉัน เห็นได้ชัดว่านี่จะไม่ทำงานเมื่อเราเปิดตัวเนื่องจากข้อมูลการผลิต nuking เป็นสูตรสำหรับภัยพิบัติฉันจึงสงสัยว่ามีกลยุทธ์ใดบ้างในการจัดการ schema ของฐานข้อมูลที่เปลี่ยนแปลงจากรุ่นหนึ่ง / รุ่นอื่น

บางอย่างที่ฉันพบหรือมีประสบการณ์:

1. ตรง nuke-and-dump จากฐานข้อมูลหนึ่งไปยังอีกฐานข้อมูล (สิ่งที่ฉันทำตอนนี้)
2. การดูแลรักษาไฟล์ UPDATE.sql ด้วยคำสั่ง SQL ที่เรียกใช้ผ่านสคริปต์หรือด้วยมือ
3. การบำรุงรักษาไฟล์ update.php ด้วยค่า "db-schema-version" ที่สอดคล้องกันในฐานข้อมูลที่ใช้งานอยู่

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

ดูเหมือนว่าจะไม่มีปัญหา แต่เกิดขึ้นเนื่องจากเราเป็นทีมเราใช้ phpMyAdmin และฉันไม่สามารถพึ่งพาตัวเองได้จำการคัดลอกคำสั่ง SQL ที่เรียกใช้เพื่อวางลงในไฟล์ update.php เมื่อคุณนำทางไปยังหน้าอื่นฉันต้องเขียนคำสั่ง SQL ด้วยมืออีกครั้งหรือย้อนกลับการเปลี่ยนแปลงของฉันและทำมันอีกครั้ง

ฉันเดาว่าสิ่งที่ฉันหวังคือโซลูชันที่ไม่ส่งผลกระทบต่อเวิร์กโฟลว์การพัฒนาของเราหรือไม่

ได้โดยอัตโนมัติ ได้โดยอัตโนมัติ ได้โดยอัตโนมัติ

คุณกำลังติดตามถูกต้องด้วยหมายเลขรุ่น DB ชัดเจน แต่ฉันจะไปอีกขั้นและทำให้รหัสทราบอย่างชัดเจนว่า schema สิ่งที่คาดว่าจะทำงานกับ (เช่นโดยการยอมรับสคริปต์ DDL จริงและมีการปรับปรุงแยกวิเคราะห์มัน ); เมื่อถึงเวลาอัปเดตคุณจะต้องค้นพบสกีมาที่มีอยู่ผ่านเมตาดาต้าฐานข้อมูลและ INSERT / DROP / ALTER ตามความจำเป็นไม่ว่าจากเวอร์ชันใดไปจนถึงเวอร์ชันที่คุณกำลังอัปเดต (คุณสามารถเก็บหมายเลขรุ่นที่ชัดเจนในฐานข้อมูลของตัวเองและส่งประวัติ schema ทั้งหมดด้วยโปรแกรมติดตั้งเพื่อให้คุณไม่จำเป็นต้องค้นหา schema ด้วยซ้ำ)

ข้อผิดพลาดทางไวยากรณ์ที่เป็นไปได้ในสคริปต์ SQL update เป็นปัญหา แต่คุณสามารถแก้ไขได้โดยการตรวจสอบว่า updater สามารถสร้างคำสั่ง DDL ที่ถูกต้องเท่านั้น (หลักฐานที่เป็นทางการแทบจะไม่คุ้มค่าในการพัฒนาซอฟต์แวร์องค์กร - ความพยายามมากเกินไปสำหรับการรับประกันน้อยเกินไป - แต่ฉันรู้สึกว่าความสมบูรณ์ของฐานข้อมูลเป็นหนึ่งในข้อยกเว้นบางประการ: SQL พื้นฐานไม่ใช่ภาษาที่ยากเป็นพิเศษในการจับภาพอย่างเป็นทางการ การปกป้องข้อมูลการผลิตนั้นยอดเยี่ยมจนเกือบทุกครั้งที่มีความพยายามล่วงหน้าเป็นธรรมโดยเฉพาะอย่างยิ่งหากต้องทำงานเพื่อติดตั้งแบบอัตโนมัติ)

การกำหนดเวอร์ชันสกีมาฐานข้อมูลเป็นวิธีการดำเนินการ - แต่ละเวอร์ชันมีการเปลี่ยนแปลงฐานข้อมูลเพียงครั้งเดียวหรืออย่างน้อยการเปลี่ยนแปลงที่สามารถเปลี่ยนกลับเป็นทั้งหมด DBDeployเป็นเครื่องมือที่ยอดเยี่ยมในการทำให้เป็นอัตโนมัติ

สิ่งที่ฉันได้เรียนรู้มีประโยชน์คือ:

1. เสมอทดสอบการเปลี่ยนแปลงของคุณภายในและทดสอบรหัสของคุณกับมันเพียงALTERผ่านไม่เพียงพอ
2. คุณต้องซิงโครไนซ์สิ่งที่ต้องทำการเปลี่ยนแปลงก่อน - หน้าวิกิแบบง่าย ๆ ที่คุณสามารถ "รับหมายเลข" ได้ผลดีสำหรับทีมของฉัน
3. อย่าพยายามแก้ไขการเปลี่ยนแปลงที่เสียหายเพิ่มการเปลี่ยนแปลงการเปลี่ยนแปลงใหม่เพื่อลบล้างมันไม่เจ็บปวดมากนัก
4. รหัสของคุณขึ้นอยู่กับการเปลี่ยนแปลงนั้น - ให้แน่ใจว่าได้เชื่อมโยงปัญหาในระบบติดตามบั๊กของคุณกับการเปลี่ยนแปลงฐานข้อมูล มีประโยชน์มากในเวลาที่ใช้งาน
5. รวมการเปลี่ยนแปลงฐานข้อมูลกับ CI ของคุณ - นำการเปลี่ยนแปลงของคุณไปใช้กับฐานข้อมูล CI นอกจากนี้หากคุณมีการทดสอบใด ๆ ที่ใช้ฐานข้อมูลให้ทำการทดสอบ

เนื่องจากคุณกำลังใช้ phpMyAdmin ดังนั้นฉันคิดว่าคุณใช้ MySQL เช่นกัน

ดูไดอะแกรม EER Model ใน MySQL Workbench พวกเขาช่วยฉันอย่างมากในการบำรุงรักษาและอัปเดตสคีมา

ก่อนอื่นคุณสามารถซิงโครไนซ์โมเดลกับแหล่งฐานข้อมูล ดังนั้นการเปลี่ยนแปลงในไดอะแกรมจะถูกผลักออกมาเป็นคำสั่ง ALTER TABLE สิ่งนี้ช่วยให้คุณสามารถทำการเปลี่ยนแปลงสคีมาของคุณบนไดอะแกรมปรับปรุงให้ทันสมัยอยู่เสมอในขณะที่ยังอัปเดตฐานข้อมูลการพัฒนาของคุณเมื่อต้องการ

ประการที่สองคุณสามารถสร้างไดอะแกรม EER ย้อนกลับจากแหล่งฐานข้อมูล ซึ่งมีประโยชน์โดยทำการเปลี่ยนแปลงในฐานข้อมูลการพัฒนาและปรับปรุงฐานข้อมูลการผลิตเนื่องจากจะคำนวณความแตกต่าง

ประการที่สามมันสามารถใช้เพื่อช่วยในการสร้าง SQL ที่ควรเข้าไปในไฟล์ "update.sql" ของคุณ

ข้อเสีย:

ทริกเกอร์และข้อ จำกัด ของฐานข้อมูลเป็นปัญหากับตัวอัพเดทซิงโครไนซ์ ดูเหมือนจะไม่ทราบลำดับที่ถูกต้องของสิ่งต่าง ๆ ข้อ จำกัด คีย์ต่างประเทศมักสร้างข้อผิดพลาด แต่สามารถแก้ไขได้โดยการแก้ไข SQL ที่สร้างขึ้น

นี่ไม่ใช่เครื่องมือย้ายข้อมูล การเปลี่ยนแปลงใด ๆ ที่อยู่นอกเหนือจาก schema ล้วน ๆ จะยังคงต้องการ SQL แบบกำหนดเอง

ลองดูที่http://south.aeracode.org - เป็นคลังข้อมูลการย้ายฐานข้อมูลสำหรับ Django (กรอบ Python) แต่:

1. คุณสามารถรับความคิดที่ดีจากมัน (และอาจพบ PHP โคลน)
2. คุณสามารถใช้งานได้อย่างอิสระจาก Django เพื่อจัดการตารางของแอพ PHP / MySQL ของคุณ

นอกจากนี้ยังสามารถสร้างสคริปต์การปรับปรุงสคีมา; นอกจากนี้ยังจัดการการพลิกกลับการเปลี่ยนแปลงโดยอัตโนมัติเกือบตลอดเวลา