เมื่อทำงานในทีมนักพัฒนาที่ทุกคนทำการเปลี่ยนแปลงตารางท้องถิ่นและตารางการพัฒนาคุณจะเปลี่ยนแปลงการซิงค์ทั้งหมดอย่างไร ไฟล์บันทึกกลางที่ทุกคนเก็บการเปลี่ยนแปลงของ sql หรือไม่ หน้าวิกิเพื่อติดตามแก้ไขคำสั่งตาราง, ไฟล์. sql แต่ละไฟล์ที่ devs สามารถรันเพื่อนำโลคัล db ไปเป็นเวอร์ชันล่าสุดได้หรือไม่? ฉันใช้วิธีแก้ปัญหาเหล่านี้แล้วและฉันก็คาดหวังว่าจะได้วิธีแก้ปัญหาที่ดีร่วมกันซึ่งใช้งานได้ดีดังนั้นฉันจึงขอขอบคุณความคิดของคุณ
คำตอบ:
ฉันใช้เครื่องมือการย้ายฐานข้อมูลตามรหัสและเก็บรหัสการโยกย้ายไว้ในการควบคุมแหล่งที่มา
ด้วยการใช้การประทับเวลาเป็นหมายเลขเวอร์ชันจำนวน devs ใด ๆ สามารถเพิ่มการโยกย้ายได้ตามต้องการและเราสามารถเรียกใช้เครื่องมือการโยกย้ายเทียบกับสำเนาของฐานข้อมูลใด ๆ ของเราอย่างมั่นใจ
ฉันเคยใช้สคริปต์ SQL ภายใต้การควบคุมเวอร์ชัน แต่พบว่าวิธีการทำงานแบบใช้โค้ดนั้นง่ายกว่ามากเนื่องจากพวกเขาทั้งหมดอยู่ใน "สปอต" แบบลอจิคัลเดียวและสามารถเรียกใช้สคริปต์ที่จำเป็นทั้งหมดด้วยคำสั่งเดียว
ฉันไม่ได้ทำเอง แต่นักพัฒนาบางคนเก็บรวบรวมสคริปต์ SQL ไว้ภายใต้การควบคุมของแหล่งที่ซึ่งเมื่อดำเนินการแล้วสามารถสร้างตารางฐานข้อมูลขึ้นมาใหม่เพื่อการทดสอบและสร้างฐานข้อมูลเปล่าเพื่อการผลิต
สามารถใช้เทคนิคเดียวกันนี้เพื่อจัดทำฐานข้อมูลที่ไซต์ลูกค้าเมื่อจำเป็นต้องเพิ่มหรือลบเขตข้อมูลหรือตารางหรือต้องมีการแปลงข้อมูล
สร้างสคริปต์ภายใต้การควบคุมเวอร์ชันและการรวมอย่างต่อเนื่องเพื่อตรวจสอบพวกเขา
วิธีหนึ่งที่เหมาะกับฉันคือการให้นักพัฒนาซอฟต์แวร์แต่ละคนทำงานร่วมกับสคีมาของตนเองซึ่งพวกเขาสามารถทำสิ่งที่พวกเขาชอบได้ สคีมาของพวกเขานั้นถูกทำลายและบรรจุด้วยข้อมูลทดสอบที่นำมาจากชุดควบคุมสคริปต์ที่นักพัฒนาซอฟต์แวร์ทุกคนมีส่วนร่วม
โครงสร้างการรวมระบบอย่างต่อเนื่องทุกคืนนั้นใช้สคริปต์เวอร์ชันล่าสุดทั้งหมดและพยายามสร้างฐานข้อมูลการทดสอบที่เหนียวแน่นจากพวกเขา แอปพลิเคชันนั้นมีชุดของการรวมและการทดสอบการทำงานกับมันเพื่อตรวจสอบว่าคีมาปัจจุบันสอดคล้องกับผู้สมัครรุ่นปัจจุบัน
ก่อนที่จะเริ่มต้นลงบนถนนนี้มีการออกแบบฐานข้อมูลที่ค่อนข้างแน่นหนาและ DBA คอยจับตาดูสิ่งต่าง ๆ เสมอเพื่อป้องกันไม่ให้ผู้พัฒนาคลั่งไคล้กับสภาพปกติและความน่ากลัวอื่น ๆ
การควบคุมเวอร์ชันช่วยอย่างมากที่นี่เพราะการเปลี่ยนแปลงสคริปต์มีความชัดเจนในทันที นอกจากนี้เรายังใช้VERSIONตารางฐานข้อมูลเพื่อระบุสถานะโดยรวมของฐานข้อมูล นี่เป็นลำดับเลขจำนวนเต็มอย่างง่ายและไม่ได้เชื่อมโยงกับแอปพลิเคชันใด ๆ โดยเฉพาะ
โดยรวมแล้วมันใช้งานได้ดีและหมายความว่านักพัฒนาซอฟต์แวร์หยุดกลัวที่จะเปลี่ยนระดับการคงอยู่เพราะพวกเขาสามารถย้อนกลับสกีมาของตนเองได้โดยไม่ส่งผลกระทบต่อผู้อื่น
หากคุณอยู่ในร้านค้า MS Visual Studio 2010 มีเครื่องมือควบคุมเวอร์ชันฐานข้อมูลที่ดีซึ่งสามารถสร้างสคริปต์การเปลี่ยนแปลง / การปรับใช้ตามความแตกต่างระหว่างฐานข้อมูลสองแห่ง
พร้อมกับการรักษา schemata และสคริปต์ SQL อื่น ๆ ภายใต้การควบคุมเวอร์ชันอื่นปฏิบัติที่มีประโยชน์คือการรักษา 'รุ่นสคี' ตารางในฐานข้อมูลที่เกิดขึ้นจริง
create table schema_migrations (
`appliedAt` timestamp not null default CURRENT_TIMESTAMP,
`migrationCode` varchar(256) not null,
`extraNotes` varchar(256),
primary key (`migrationCode`)
)Doctrine มีเครื่องมือการย้ายที่ยอดเยี่ยม: http://www.doctrine-project.org/documentation/manual/1_2/en/migrationsส่วนที่ดีที่สุดคือพวกมันถูกสร้างอัตโนมัติหรือสามารถเขียนด้วยมือได้อย่างง่ายดาย
วิธีการที่ฉันใช้คือจัดเตรียมตารางหนึ่งพารามิเตอร์ ตารางนี้จะมีคู่ชื่อ / ค่าหนึ่งคู่สำหรับรุ่นที่ฐานข้อมูลเปิดอยู่ สิ่งนี้ให้ประโยชน์สองประการแก่ฉัน: ฉันมีวิธีการตรวจสอบฐานข้อมูลเฉพาะการแก้ไขที่ใช้ผ่านแอปพลิเคชันและฉันสามารถใช้ค่านั้นกับสคริปต์ SQL ของฉัน
สคริปต์ SQL จะสร้างตารางใหม่แก้ไขคอลัมน์และงานใด ๆ ที่จำเป็นในฐานข้อมูลเพื่อโปรโมตสคริปต์จากเวอร์ชันก่อนหน้านี้ เป็นการดีที่ฉันจะมีสคริปต์ย้อนกลับ แต่ส่วนใหญ่ฉันไม่
BTW วิธีการทั้งหมดนี้เป็นแบบอัตโนมัติซึ่งเป็นส่วนหนึ่งของ Ruby on Rails พร้อมด้วยสคริปต์ย้อนกลับ ฉันชอบความคิดของสิ่งนั้น แต่ไม่ใช่ทุกเฟรมเวิร์คที่ทำเช่นนั้น เมื่อฉันไม่ได้ใช้ Ruby on Rails ฉันใช้วิธีที่อธิบายไว้ข้างต้น