มีระบบควบคุมเวอร์ชันสำหรับการเปลี่ยนแปลงโครงสร้างฐานข้อมูลหรือไม่?

ฉันมักจะพบปัญหาต่อไปนี้

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

ดังนั้นฉันจึงผลักดันระบบถ่ายทอดสดและได้รับข้อผิดพลาดใหญ่ที่ชัดเจนว่าไม่มีNewColumnXฮึ

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

ใน Ruby on Rails มีแนวคิดเกี่ยวกับการย้าย - สคริปต์ด่วนเพื่อเปลี่ยนฐานข้อมูล

คุณสร้างไฟล์การย้ายข้อมูลซึ่งมีกฎในการเพิ่มเวอร์ชันฐานข้อมูล (เช่นการเพิ่มคอลัมน์) และกฎในการดาวน์เกรดเวอร์ชัน (เช่นการลบคอลัมน์) การย้ายข้อมูลแต่ละครั้งจะมีหมายเลขกำกับไว้และตารางจะติดตามเวอร์ชันฐานข้อมูลปัจจุบันของคุณ

ในการย้ายข้อมูลให้เรียกใช้คำสั่งที่เรียกว่า "db: migrate" ซึ่งจะดูเวอร์ชันของคุณและใช้สคริปต์ที่จำเป็น คุณสามารถย้ายข้อมูลลงในลักษณะเดียวกัน

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

ฉันเป็นคนแก่หน่อยที่ฉันใช้ซอร์สไฟล์ในการสร้างฐานข้อมูล จริงๆแล้วมี 2 ไฟล์คือ project-database.sql และ project-updates.sql - ไฟล์แรกสำหรับสคีมาและข้อมูลที่คงอยู่และไฟล์ที่สองสำหรับการปรับเปลี่ยน แน่นอนว่าทั้งสองอย่างอยู่ภายใต้การควบคุมแหล่งที่มา

เมื่อฐานข้อมูลเปลี่ยนแปลงฉันจะอัปเดต schema หลักใน project-database.sql ก่อนจากนั้นคัดลอกข้อมูลที่เกี่ยวข้องไปยัง project-updates.sql เช่นคำสั่ง ALTER TABLE จากนั้นฉันสามารถใช้การอัปเดตกับฐานข้อมูลการพัฒนาทดสอบทำซ้ำจนกว่าจะทำได้ดี จากนั้นตรวจสอบไฟล์ทดสอบอีกครั้งและนำไปใช้กับการผลิต

นอกจากนี้ฉันมักจะมีตารางใน db - Config - เช่น:

SQL

CREATE TABLE Config
(
    cfg_tag VARCHAR(50),
    cfg_value VARCHAR(100)
);

INSERT INTO Config(cfg_tag, cfg_value) VALUES
( 'db_version', '$Revision: $'),
( 'db_revision', '$Revision: $');

จากนั้นฉันเพิ่มสิ่งต่อไปนี้ในส่วนการอัปเดต:

UPDATE Config SET cfg_value='$Revision: $' WHERE cfg_tag='db_revision';

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

ฉันสามารถเก็บการอัปเดตไว้ในไฟล์แยกต่างหากของตัวเองได้ แต่ฉันเลือกที่จะรวมเข้าด้วยกันและใช้การตัดและวางเพื่อแยกส่วนที่เกี่ยวข้อง การดูแลทำความสะอาดอีกเล็กน้อยเป็นไปตามลำดับกล่าวคือลบ ':' จาก $ Revision 1.1 $ เพื่อตรึงไว้

MyBatis (เดิมชื่อ iBatis) มีการโยกย้ายสคีมาซึ่งเป็นเครื่องมือสำหรับใช้ในบรรทัดคำสั่ง มันเขียนด้วย java แม้ว่าจะสามารถใช้กับโปรเจ็กต์ใดก็ได้

เพื่อให้บรรลุแนวปฏิบัติในการจัดการการเปลี่ยนแปลงฐานข้อมูลที่ดีเราจำเป็นต้องระบุเป้าหมายสำคัญบางประการ ดังนั้นระบบการย้าย MyBatis Schema (หรือ MyBatis Migrations สำหรับระยะสั้น) จึงพยายามที่จะ:

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

redgate มีผลิตภัณฑ์ที่เรียกว่าSQL ควบคุมแหล่งที่มา ทำงานร่วมกับ TFS, SVN, SourceGear Vault, Vault Pro, Mercurial, Perforce และ Git

ผมขอแนะนำให้SQL เดลต้า ฉันใช้มันเพื่อสร้างสคริปต์ที่แตกต่างเมื่อฉันเขียนโค้ดคุณสมบัติของฉันเสร็จแล้วและตรวจสอบสคริปต์เหล่านั้นในเครื่องมือควบคุมแหล่งที่มาของฉัน (Mercurial :))

มีทั้งเซิร์ฟเวอร์ SQL และเวอร์ชัน Oracle

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

<createTable tableName="USER"> 
   <column name="firstname" type="varchar(255)"/>
</createTable>

ดังนั้นคุณไม่จำเป็นต้องจัดการเรื่องนี้ด้วยตัวคุณเอง

นอกจากนี้ยังรองรับคำสั่ง pure sql หรือการนำเข้าข้อมูล

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

หากคุณใช้ SQL Server คงยากที่จะเอาชนะ Data Dude (หรือที่เรียกว่า Database Edition ของ Visual Studio) เมื่อคุณได้รับการแฮงค์แล้วการเปรียบเทียบสคีมาระหว่างฐานข้อมูลเวอร์ชันที่ควบคุมด้วยซอร์สและเวอร์ชันที่ใช้งานจริงนั้นเป็นเรื่องง่าย และด้วยการคลิกคุณสามารถสร้าง DDL ที่แตกต่างกันได้

มีวิดีโอการเรียนการสอนเกี่ยวกับ MSDN ที่มีประโยชน์มาก

ฉันรู้เกี่ยวกับ DBMS_METADATA และ Toad แต่ถ้ามีใครสักคนสามารถหา Data Dude สำหรับ Oracle ได้ชีวิตก็จะหวานจริงๆ

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

ส่วนที่ยากที่สุดที่ฉันเห็นคือการติดตามการอ้างอิงเช่นสำหรับตารางการปรับใช้เฉพาะ B อาจต้องอัปเดตก่อนตาราง A

สำหรับ Oracle ฉันใช้Toadซึ่งสามารถดัมพ์สคีมาไปยังไฟล์แยกจำนวนมาก (เช่นหนึ่งไฟล์ต่อตาราง) ฉันมีสคริปต์บางตัวที่จัดการคอลเล็กชันนี้ใน Perforce แต่ฉันคิดว่ามันควรจะทำได้ง่าย ๆ ในระบบควบคุมการแก้ไขใด ๆ

ดูที่ oracle package DBMS_METADATA

โดยเฉพาะอย่างยิ่งวิธีการต่อไปนี้มีประโยชน์อย่างยิ่ง:

• DBMS_METADATA.GET_DDL
• DBMS_METADATA.SET_TRANSFORM_PARAM
• DBMS_METADATA.GET_GRANTED_DDL

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

ไม่แน่ใจว่ามีอะไรง่ายๆสำหรับ MSSQL หรือไม่

ฉันเขียนสคริปต์รีลีส db ของฉันควบคู่ไปกับการเข้ารหัสและเก็บสคริปต์รีลีสไว้ในส่วนเฉพาะโปรเจ็กต์ใน SS หากฉันทำการเปลี่ยนแปลงรหัสที่ต้องมีการเปลี่ยนแปลงฐานข้อมูลฉันจะอัปเดตสคริปต์รุ่นในเวลาเดียวกัน ก่อนที่จะเผยแพร่ฉันเรียกใช้สคริปต์การเผยแพร่บนฐานข้อมูล dev ที่สะอาด (โครงสร้างที่คัดลอกมาจากการผลิตอย่างชาญฉลาด) และทำการทดสอบขั้นสุดท้ายกับมัน

ฉันทำสิ่งนี้มาหลายปีแล้ว - จัดการ (หรือพยายามจัดการ) เวอร์ชันสคีมา แนวทางที่ดีที่สุดขึ้นอยู่กับเครื่องมือที่คุณมี หากคุณได้รับเครื่องมือ Quest Software "Schema Manager" คุณจะมีรูปร่างที่ดี Oracle มีเครื่องมือที่ด้อยกว่าของตัวเองซึ่งเรียกว่า "Schema Manager" (สับสนมาก?) ที่ฉันไม่แนะนำ

หากไม่มีเครื่องมืออัตโนมัติ (ดูความคิดเห็นอื่น ๆ เกี่ยวกับ Data Dude) คุณจะใช้สคริปต์และไฟล์ DDL โดยตรง เลือกแนวทางจัดทำเอกสารและปฏิบัติตามอย่างเคร่งครัด ฉันชอบที่มีความสามารถในการสร้างฐานข้อมูลใหม่ในช่วงเวลาใดเวลาหนึ่งดังนั้นฉันจึงต้องการส่งออก DDL แบบเต็มของฐานข้อมูลทั้งหมด (ถ้าฉันเป็น DBA) หรือของสคีมาของนักพัฒนา (ถ้าฉันอยู่ในผลิตภัณฑ์ - โหมดการพัฒนา)

PLSQL Developer ซึ่งเป็นเครื่องมือจาก All Arround Automations มีปลั๊กอินสำหรับที่เก็บที่ทำงานได้ดี (แต่ไม่ดีมาก) ด้วย Visual Source Safe

จากเว็บ:

ปลั๊กอินการควบคุมเวอร์ชันให้การรวมที่แน่นหนาระหว่าง PL / SQL Developer IDE >> และระบบควบคุมเวอร์ชันใด ๆ ที่สนับสนุนข้อกำหนดอินเทอร์เฟซ Microsoft SCC >> ซึ่งรวมถึงระบบควบคุมเวอร์ชันยอดนิยมเช่น Microsoft Visual SourceSafe >> Merant PVCS และ MKS Source Integrity

http://www.allroundautomations.com/plsvcs.html

ER Studioช่วยให้คุณสามารถย้อนกลับ schema ฐานข้อมูลของคุณลงในเครื่องมือจากนั้นคุณสามารถเปรียบเทียบกับฐานข้อมูลที่ใช้งานได้

ตัวอย่าง: ย้อนกลับสคีมาการพัฒนาของคุณเป็น ER Studio - เปรียบเทียบกับการใช้งานจริงและจะแสดงรายการความแตกต่างทั้งหมด สามารถเขียนสคริปต์การเปลี่ยนแปลงหรือเพียงแค่ผลักดันให้ผ่านโดยอัตโนมัติ

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

มี "กรอบการย้ายฐานข้อมูล" PHP5 ที่เรียกว่า Ruckusing ฉันไม่ได้ใช้มัน แต่ตัวอย่างแสดงแนวคิดหากคุณใช้ภาษาเพื่อสร้างฐานข้อมูลตามที่ต้องการคุณจะต้องติดตามไฟล์ต้นฉบับเท่านั้น

คุณสามารถใช้Microsoft SQL Server Data Toolsใน Visual Studio เพื่อสร้างสคริปต์สำหรับวัตถุฐานข้อมูลโดยเป็นส่วนหนึ่งของโครงการ SQL Server จากนั้นคุณสามารถเพิ่มสคริปต์ในการควบคุมแหล่งที่มาโดยใช้การรวมตัวควบคุมแหล่งที่มาที่สร้างขึ้นในสตูดิโอภาพ นอกจากนี้โครงการเซิร์ฟเวอร์ SQL ยังอนุญาตให้คุณตรวจสอบวัตถุฐานข้อมูลโดยใช้คอมไพเลอร์และสร้างสคริปต์การปรับใช้เพื่ออัพเดตฐานข้อมูลที่มีอยู่หรือสร้างขึ้นใหม่

เราใช้MS Team System Database Editionซึ่งประสบความสำเร็จอย่างดี มันรวมเข้ากับการควบคุมเวอร์ชัน TFS และ Visual Studio ไม่มากก็น้อยอย่างราบรื่นและช่วยให้เราจัดการ procs มุมมอง ฯลฯ ที่เก็บไว้ได้อย่างง่ายดาย การแก้ปัญหาความขัดแย้งอาจเป็นเรื่องยาก แต่ประวัติเวอร์ชันจะเสร็จสมบูรณ์เมื่อเสร็จสิ้น หลังจากนั้นการโยกย้ายไปยัง QA และการผลิตนั้นง่ายมาก

เป็นเรื่องยุติธรรมที่จะกล่าวได้ว่าเป็นผลิตภัณฑ์เวอร์ชัน 1.0 และไม่มีปัญหาเล็กน้อย

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

http://www.red-gate.com/Products/schema_compare_for_oracle/index.htm

ในกรณีที่ไม่มี VCS สำหรับการเปลี่ยนแปลงตารางฉันได้บันทึกไว้ในวิกิ อย่างน้อยฉันก็สามารถเห็นได้ว่าเมื่อใดและเหตุใดจึงมีการเปลี่ยนแปลง มันยังห่างไกลจากความสมบูรณ์แบบเนื่องจากไม่ใช่ทุกคนที่ทำและเรามีผลิตภัณฑ์หลายรุ่นที่ใช้งานอยู่ แต่ดีกว่าไม่มีอะไรเลย

ฉันขอแนะนำหนึ่งในสองวิธี ขั้นแรกลงทุนในPowerDesignerจาก Sybase Enterprise Edition ช่วยให้คุณออกแบบข้อมูลทางกายภาพและอื่น ๆ อีกมากมาย แต่มาพร้อมกับพื้นที่เก็บข้อมูลที่ช่วยให้คุณตรวจสอบโมเดลของคุณได้ การเช็คอินใหม่แต่ละครั้งอาจเป็นเวอร์ชันใหม่สามารถเปรียบเทียบเวอร์ชันใดก็ได้กับเวอร์ชันอื่น ๆ และแม้กระทั่งกับสิ่งที่อยู่ในฐานข้อมูลของคุณในขณะนั้น จากนั้นจะนำเสนอรายการของความแตกต่างทั้งหมดและถามว่าควรย้ายข้อมูลใด ... จากนั้นจะสร้างสคริปต์เพื่อทำ มันไม่ถูก แต่เป็นการต่อรองที่ราคาสองเท่าและ ROI อยู่ที่ประมาณ 6 เดือน

อีกแนวคิดหนึ่งคือการเปิดการตรวจสอบ DDL (ทำงานใน Oracle) สิ่งนี้จะสร้างตารางพร้อมการเปลี่ยนแปลงทุกอย่างที่คุณทำ หากคุณสอบถามการเปลี่ยนแปลงจากการประทับเวลาที่คุณย้ายฐานข้อมูลครั้งล่าสุดที่เปลี่ยนแปลงไปเป็น prod ในตอนนี้คุณจะมีรายการสั่งซื้อของทุกสิ่งที่คุณทำ ไม่กี่คำสั่งในการกำจัดการเปลี่ยนแปลงผลรวมศูนย์เช่นสร้างตาราง foo; ตามด้วย drop table foo; และคุณสามารถสร้างสคริปต์ mod ได้อย่างง่ายดาย ทำไมถึงเก็บการเปลี่ยนแปลงไว้ใน wiki นั่นคืองานสองเท่า ให้ฐานข้อมูลติดตามให้คุณ

คำแนะนำหนังสือสองเล่ม: "Refactoring Databases" โดย Ambler และ Sadalage และ "Agile Database Techniques" โดย Ambler

มีคนพูดถึง Rails Migrations ฉันคิดว่ามันใช้งานได้ดีแม้จะอยู่นอกแอปพลิเคชัน Rails ฉันใช้มันในแอปพลิเคชัน ASP กับ SQL Server ซึ่งเราอยู่ในขั้นตอนการย้ายไปที่ Rails คุณตรวจสอบสคริปต์การย้ายข้อมูลเองใน VCS นี่คือโพสต์ของ Pragmatic Dave Thomasในหัวข้อนี้