ไฟล์ฐานข้อมูล (สคริปต์ ฯลฯ ) ควรอยู่ในการควบคุมแหล่งที่มาหรือไม่ ถ้าอย่างนั้นเป็นวิธีที่ดีที่สุดในการเก็บไว้และอัปเดตที่นั่น?

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

วิธีใดที่ใช้ดีที่สุดสำหรับฐานข้อมูลในการควบคุมแหล่งที่มา?

ใช่. คุณควรจะสามารถสร้างส่วนหนึ่งส่วนใดของระบบของคุณจากการควบคุมแหล่งรวมถึงฐานข้อมูล (และฉันจะเถียงข้อมูลคงที่บางอย่าง)

สมมติว่าคุณไม่ต้องการมีเครื่องมือในการทำเช่นนั้นฉันขอแนะนำให้คุณรวมสิ่งต่อไปนี้ไว้ด้วย:

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

สคริปต์ทั้งหมดควรมีคำสั่งการปล่อยที่เหมาะสมและเขียนเพื่อให้สามารถเรียกใช้ในฐานะผู้ใช้ใด ๆ (รวมถึงคำนำหน้าสคีมา / เจ้าของที่เกี่ยวข้องถ้าเกี่ยวข้อง)

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

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

ใช่.

เป็นวิธีที่ดีที่สุดในการเก็บไว้และอัปเดตที่นั่น?

หนอ เขียนสคริปต์ schema-builder ตรวจสอบในหลังจากทำการเปลี่ยนแปลง ตรวจสอบก่อนที่จะรัน

มันยากที่จะตัดสินว่าคุณต้องการอะไร

เขียนสคริปต์การย้ายสคีมาอย่างเป็นทางการ ตรวจสอบพวกเขาหลังจากการทดสอบ ตรวจสอบพวกเขาออกก่อนที่จะเรียกใช้พวกเขา

มีอะไรอีกบ้าง?

สิ่งที่เกิดขึ้นคือการเปลี่ยนแปลงของสคีกลายเป็นปัญหาที่เกิดขึ้นไม่บ่อยนักเนื่องจากสคีมานั้นมีวิวัฒนาการอย่างเป็นระบบผ่านชุดการเปลี่ยนแปลงที่ไม่มีเอกสาร

วิวัฒนาการออร์แกนิกนี้ทำให้การย้ายสคีมายากขึ้นเพราะไม่มีแหล่ง "เชื่อถือ" สำหรับสิ่งที่ควรมี มีสองเวอร์ชันการผลิตที่แตกต่างกันเล็กน้อยคือ staging, QA และแปดพัฒนา ทั้งหมดแตกต่างกันเล็กน้อย

หากมีแหล่งข้อมูลที่เชื่อถือได้เพียงแหล่งเดียวการโยกย้ายสกีมาเป็นเพียงส่วนที่แตกต่างระหว่างเวอร์ชันล่าสุดและรุ่นนี้

ใช่

สคริปต์ฐานข้อมูล (ddl, dml) เป็นรหัส รหัสทั้งหมดควรอยู่ในระบบควบคุมเวอร์ชัน

การโยกย้าย

• ใช้การย้ายฐานข้อมูล

อนุญาตให้คุณใช้ไฟล์ db เดียวกันในการพัฒนา qa และรีลีส

• ปล่อยไปยังฐานข้อมูลด้วยหมายเลขรุ่น

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

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

เราได้พยายามทำสิ่งนี้โดยอัตโนมัติด้วยเครื่องมือเปรียบเทียบฐานข้อมูล (เปรียบเทียบข้อมูลหลักเทียบกับฐานข้อมูลลูกค้า) และสิ่งนั้นช่วย แต่คุณไม่สามารถเชื่อถือเครื่องมือดังกล่าวได้ 100% คุณต้องมีกระบวนการตรวจสอบด้วยเช่นกัน

ใช่

และ Furthemore คุณจะต้องการสาขา

ฉันใช้ Git สำหรับสาขา:

• เพื่อการพัฒนาต่อคุณสมบัติ (เช่นเดียวกับที่เราทำเพื่อการพัฒนาแอพพลิเคชั่นที่เหลือตามปกติ)

• และอีกอันสำหรับเซิร์ฟเวอร์ที่ใช้งานจริงเช่นกันเนื่องจากลูกค้าที่ใช้แอปพลิเคชันสร้างเนื้อหาเช่นกัน

ด้วยวิธีนี้คุณจะได้รับประโยชน์จากการควบคุมแหล่งที่มาและการแตกแขนงสำหรับทั้งซอร์สโค้ดและฐานข้อมูล (และไฟล์อื่น ๆ ที่คุณมี)

ฉันยังไม่พบระบบ all-in-one [สำหรับ PostgreSQL] ดังนั้นฉันจึงต้องเขียนฟังก์ชั่น / สคริปต์เพื่อสร้างดัชนีใหม่อย่างถูกต้องเมื่อรวมสาขา (เช่นดัชนีจากสาขาการผลิตไม่ควรแก้ไขเพราะลูกค้าพึ่งพาพวกเขาในขณะที่ ดัชนี + คีย์ต่างประเทศจากสาขาการพัฒนาที่ตัดกับเนื้อหาการผลิตควรถูกทำดัชนีใหม่: มันไม่สามารถใช้ได้กับทุกแอปพลิเคชัน แต่ครอบคลุมทุกกรณีของแอปพลิเคชันของเราดังนั้นมันจึงดีพอ)

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

สำหรับ Java ทีมของเราใช้Flywayซึ่งเราพบว่าใช้งานง่ายและทรงพลัง

หากคุณกำลังทำงานใน Ruby, Rails มีการย้ายข้อมูลซึ่งเป็นวิธีที่มีประสิทธิภาพในการจัดการกับปัญหานี้

Liquibaseได้รับการกล่าวถึงแล้ว - เป็นวิธีแก้ปัญหาที่ดี แต่ฉันพบว่ายุ่งยากกว่าทางเลือกอื่นเช่น Flyway

นอกจากนี้ซอฟต์แวร์ RedGate ยังเสนอผลิตภัณฑ์ที่เรียกว่าSQL Source Controlที่ออกแบบมาสำหรับ SQL Server ฉันไม่ได้ใช้มัน แต่เพื่อนร่วมงานคนหนึ่งของฉันบอกว่ามันยอดเยี่ยม

นี่คือปัญหาที่ฉันเคยเห็นหลายครั้งเมื่อไม่มีการควบคุมเวอร์ชันหรือการจัดการการเปลี่ยนแปลงในฐานข้อมูลการพัฒนา โปรแกรมเมอร์ A เปลี่ยนตารางมุมมองหรือกระบวนการ Programmer B ทำการเปลี่ยนแปลงในสิ่งเดียวกันและเขียนทับสิ่งที่โปรแกรมเมอร์ A ทำ หรือ DBA คืนค่าฐานข้อมูลการผลิตเป็นการพัฒนาและเขียนทับการเปลี่ยนแปลง ฉันเคยเห็นสิ่งประเภทนี้ก่อให้เกิดความโศกเศร้ามากมายหลายครั้งมันไม่ใช่เรื่องตลก และนี่เป็นเพียงระบบการพัฒนาเท่านั้น สิ่งต่าง ๆ อาจยุ่งเหยิงจริง ๆ เมื่อจัดเตรียม / ทดสอบและแม้แต่เซิร์ฟเวอร์ที่ใช้งานจริงก็ยังติดอยู่ในเรื่องนี้

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

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

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

มันรองรับการเพิ่ม / แก้ไข / ลดลงคอลัมน์การเรียกใช้แบบสอบถามเพิ่ม / ลดลงดัชนีข้อ จำกัด ฯลฯ มันจะติดตามสถานะฐานข้อมูลที่อยู่ในและใช้การโยกย้ายที่ขาดหายไปใด ๆ นอกจากนี้ยังช่วยให้คุณ "ย้อนเวลากลับไป" ด้วยการระบุการย้ายข้อมูลที่คุณต้องการ ( php ladder.php migrate 15)

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

DataGroveแก้ปัญหาที่กล่าวถึงที่นี่ (โดยjfrankcarrเป็นต้น)

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

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

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

MONyog มีคุณสมบัติที่เรียกว่าCSO (Custom SQL Objects) ซึ่งสามารถตรวจสอบการเปลี่ยนแปลงในชุดข้อมูลโดยเฉพาะ เพิ่ม CSO อธิบายไว้ที่นี่ ตอนนี้ในส่วนประวัติจอภาพของ MONyog คุณสามารถรับการเปลี่ยนแปลงได้ในช่วงเวลาหนึ่ง ดีที่สุดมันให้รายงานภาพในหน้า html รายงานจะมีลักษณะเช่นนี้