ฉันจะวางฐานข้อมูลภายใต้ git (การควบคุมเวอร์ชัน) ได้อย่างไร?

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

ฉันจะทำอย่างไร มีโฟลเดอร์เฉพาะที่ฉันสามารถเก็บภายใต้พื้นที่เก็บข้อมูล git หรือไม่ ฉันจะรู้ได้อย่างไรว่าอันไหน ฉันจะแน่ใจได้อย่างไรว่าฉันวางโฟลเดอร์ที่ถูกต้อง?

ฉันต้องแน่ใจเพราะการเปลี่ยนแปลงเหล่านี้ไม่สามารถใช้งานร่วมกับระบบย้อนหลังได้ ฉันไม่สามารถจะพลาด

ฐานข้อมูลในกรณีของฉันคือ PostgreSQL

แก้ไข:

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

จะต้องมีวิธีที่ดีกว่า

ปรับปรุง:

ตกลงดังนั้นจึงไม่มีวิธีที่ดีกว่านี้ แต่ฉันก็ยังไม่ค่อยมั่นใจดังนั้นฉันจะเปลี่ยนคำถามเล็กน้อย:

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

sqlite จะเป็น git-friendly หรือไม่?

เนื่องจากนี่เป็นเพียงสภาพแวดล้อมการพัฒนาฉันสามารถเลือกฐานข้อมูลใดก็ได้ที่ฉันต้องการ

Edit2:

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

ใช้ดัมพ์ฐานข้อมูลและควบคุมเวอร์ชันแทน วิธีนี้เป็นไฟล์ข้อความแบบแบน

ส่วนตัวผมขอแนะนำให้คุณเก็บทั้งการถ่ายโอนข้อมูลและการถ่ายโอนข้อมูล schema วิธีนี้ใช้ diff มันค่อนข้างง่ายที่จะเห็นสิ่งที่เปลี่ยนแปลงใน schema จากการแก้ไขเป็นการแก้ไข

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

ตรวจสอบฐานข้อมูลการปรับโครงสร้างใหม่ ( http://databaserefactoring.com/ ) สำหรับเทคนิคที่ดีมากมายในการรักษาฐานข้อมูลของคุณควบคู่กับการเปลี่ยนแปลงรหัส

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

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

ฉันเริ่มคิดถึงวิธีแก้ปัญหาที่ง่ายมากไม่รู้ว่าทำไมฉันไม่เคยคิดถึงมันมาก่อน !!

• ทำซ้ำฐานข้อมูล (ทั้งสกีมาและข้อมูล)
• ในสาขาสำหรับการเปลี่ยนแปลงครั้งสำคัญเพียงแค่เปลี่ยนการกำหนดค่าโครงการเพื่อใช้ฐานข้อมูลที่ซ้ำกันใหม่

วิธีนี้ฉันสามารถสลับสาขาได้โดยไม่ต้องกังวลเกี่ยวกับการเปลี่ยนแปลงคีมาฐานข้อมูล

แก้ไข:

ด้วยการทำซ้ำฉันหมายถึงสร้างฐานข้อมูลอื่นด้วยชื่ออื่น (เช่นmy_db_2); ไม่ได้ถ่ายโอนข้อมูลหรืออะไรทำนองนั้น

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

ต้องเผชิญกับความต้องการที่คล้ายกันและนี่คือสิ่งที่งานวิจัยของฉันเกี่ยวกับระบบควบคุมเวอร์ชันฐานข้อมูลที่สร้างขึ้น:

1. Sqitch - โอเพ่นซอร์สตามภาษา Perl พร้อมใช้งานสำหรับฐานข้อมูลหลักทั้งหมดรวมถึง PostgreSQL https://github.com/sqitchers/sqitch
2. Mahout - สำหรับ PostgreSQL เท่านั้น การควบคุมเวอร์ชันของสกีมาฐานข้อมูลโอเพ่นซอร์ส https://github.com/cbbrowne/mahout
3. Liquibase - open source db version control sw อื่น รุ่นฟรีของ Datical http://www.liquibase.org/index.html
4. Datical - Liquibase เวอร์ชันเชิงพาณิชย์ - https://www.datical.com/
5. Flyway โดย BoxFuse - โฆษณาเชิงพาณิชย์ https://flywaydb.org/
6. โครงการโอเพนซอร์ซอีกโครงการหนึ่งhttps://gitlab.com/depesz/Versioning ผู้เขียนให้แนวทางที่นี่: https://www.depesz.com/2010/08/22/versioning/
7. Red Gate Change Automation - สำหรับ SQL Server เท่านั้น https://www.red-gate.com/products/sql-development/sql-change-automation/

มีโครงการใหญ่ที่เรียกว่าการย้ายถิ่นภายใต้หลักคำสอนที่สร้างขึ้นเพื่อจุดประสงค์นี้

มันยังอยู่ในสถานะอัลฟาและสร้างขึ้นสำหรับ PHP

http://docs.doctrine-project.org/projects/doctrine-migrations/en/latest/index.html

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

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

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

ตราบใดที่คุณสามารถสร้างเดลต้าในทางทฤษฎีแล้วคอมไพล์สามารถเก็บมันได้ ปัญหาคือ git โดยปกติคาดว่าบริบทซึ่งมันสร้าง delta ของเป็นระบบไฟล์และในทำนองเดียวกันเมื่อคุณชำระเงินจุดในลำดับชั้น git ก็คาดว่าจะสร้างระบบไฟล์

หากคุณต้องการจัดการการเปลี่ยนแปลงในฐานข้อมูลคุณมีปัญหาที่ไม่ต่อเนื่อง 2 ปัญหาและฉันจะแก้ไขปัญหาเหล่านั้นแยกกัน (ถ้าฉันเป็นคุณ) ที่แรกก็คือสคีมาที่สองคือข้อมูล (แม้ว่าในคำถามของคุณคุณระบุข้อมูลไม่ใช่สิ่งที่คุณกังวล) ปัญหาที่ฉันเคยมีในอดีตคือฐานข้อมูล Dev และ Prod ซึ่ง Dev สามารถทำการเปลี่ยนแปลงที่เพิ่มขึ้นกับสคีมาและการเปลี่ยนแปลงเหล่านั้นจะต้องมีการบันทึกไว้ใน CVS และแสดงให้เห็นถึงการมีชีวิตอยู่ ตาราง เราทำอย่างนั้นโดยมีฐานข้อมูลที่ 3 เรียกว่า Cruise ซึ่งมีเฉพาะข้อมูลคงที่ ณ จุดใดสามารถเปรียบเทียบ schema จาก Dev และ Cruise และเรามีสคริปต์ที่จะใช้ diff ของ 2 ไฟล์เหล่านั้นและสร้างไฟล์ SQL ที่มีคำสั่ง ALTER เพื่อนำไปใช้ เช่นเดียวกันกับข้อมูลใหม่ใด ๆ อาจถูกกลั่นไปยังไฟล์ SQL ที่มีคำสั่ง INSERT ตราบใดที่มีการเพิ่มเขตข้อมูลและตารางเท่านั้นและไม่เคยถูกลบออกกระบวนการสามารถสร้างคำสั่ง SQL เพื่อใช้เดลต้าได้โดยอัตโนมัติ

กลไกที่คอมไพล์สร้างสันดอนเป็นdiffและกลไกที่มันรวม 1 mergeหรือมากกว่าสันดอนกับไฟล์ที่เรียกว่า หากคุณสามารถหาวิธีการที่แตกต่างและการรวมจากบริบทที่แตกต่างกันได้คอมไพล์ควรใช้งานได้ แต่ดังที่ได้กล่าวไปแล้วคุณอาจต้องการเครื่องมือที่เหมาะกับคุณ ความคิดแรกของฉันที่มีต่อการแก้ไขนั่นคือhttps://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration#External-Merge-and-Diff-Toolsซึ่งรายละเอียดวิธีการแทนที่ diff ภายในของ git และ เครื่องมือผสาน ฉันจะอัปเดตคำตอบนี้เมื่อฉันหาวิธีแก้ปัญหาที่ดีกว่า แต่ในกรณีของฉันฉันคาดหวังว่าจะต้องจัดการการเปลี่ยนแปลงข้อมูลเท่านั้นในขณะที่ฐานข้อมูลที่เก็บ DB อาจเปลี่ยนแปลงดังนั้นโซลูชันของฉัน อาจไม่ใช่สิ่งที่คุณต้องการ

ดูที่ RedGate SQL Source Control

http://www.red-gate.com/products/sql-development/sql-source-control/

เครื่องมือนี้เป็นสแน็ปอิน SQL Server Management Studio ซึ่งจะช่วยให้คุณวางฐานข้อมูลของคุณภายใต้การควบคุมแหล่งที่มาด้วย Git

มันค่อนข้างแพงที่ $ 495 ต่อผู้ใช้ แต่มีการทดลองใช้ฟรี 28 วัน

หมายเหตุฉันไม่ได้มีส่วนเกี่ยวข้องกับ RedGate แต่อย่างใด

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

ฉันจะทำตามความคิดในโพสต์นี้จากวลาดิเมีย Khorikov "ฐานข้อมูลเวอร์ชันปฏิบัติที่ดีที่สุด" โดยสรุปฉันจะ

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

ในกรณีที่ช่วย!

• Irmin
• Flur.ee
• Crux DB

ฉันได้รับการมองหาคุณสมบัติเดียวกันสำหรับ Postgres (หรือฐานข้อมูล SQL โดยทั่วไป) ในขณะที่ แต่ฉันพบว่าไม่มีเครื่องมือที่จะเหมาะสม (ง่ายและใช้งานง่าย) พอ นี่อาจเป็นเพราะลักษณะไบนารีของวิธีการจัดเก็บข้อมูล Klonioฟังดูดี แต่ดูแล้วตาย Noms DBดูน่าสนใจ ( และมีชีวิตอยู่ ) ดูที่Irmin (อิงตาม OCaml กับคุณสมบัติ Git)

แม้ว่าสิ่งนี้จะไม่ตอบคำถามว่ามันจะทำงานกับ Postgres ได้หรือไม่ลองดูที่ฐานข้อมูลFlur.ee มันมีคุณสมบัติ "การเดินทางข้ามเวลา" ที่ช่วยให้คุณสามารถค้นหาข้อมูลจากจุดใดก็ได้ในเวลา ฉันเดาว่ามันควรจะสามารถทำงานกับโมเดล "การแตกแขนง" ได้

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

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

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

Crux เป็นฐานข้อมูล bitemporal ที่เก็บเวลาการทำธุรกรรมและประวัติเวลาที่ถูกต้อง ในขณะที่ [uni] ฐานข้อมูลชั่วคราวช่วยให้ "การเดินทางข้ามเวลา" สามารถสืบค้นผ่านลำดับการทำธุรกรรมของสถานะฐานข้อมูลจากช่วงเวลาของการสร้างฐานข้อมูลไปสู่สถานะปัจจุบัน Crux ยังให้การสอบถาม "การเดินทางข้ามเวลา" สำหรับแกนเวลาที่ไม่ต่อเนื่อง ส่งผลกระทบต่อประสิทธิภาพ ซึ่งหมายความว่าผู้ใช้ Crux สามารถเติมฐานข้อมูลด้วยข้อมูลในอดีตและอนาคตโดยไม่คำนึงถึงลำดับที่ข้อมูลมาถึงและทำการแก้ไขการบันทึกที่ผ่านมาเพื่อสร้างแบบจำลองชั่วคราวของโดเมนที่กำหนด

คุณไม่สามารถทำได้โดยไม่มี atomicity และคุณไม่สามารถรับ atomicity โดยไม่ใช้ pg_dump หรือระบบไฟล์ snapshotting

อินสแตนซ์ postgres ของฉันอยู่ที่ zfs ซึ่งฉันถ่ายภาพเป็นครั้งคราว มันประมาณทันทีและสอดคล้องกัน

สิ่งที่คุณต้องการโดยสังเขปก็คือPost Factoซึ่งเก็บรุ่นของฐานข้อมูลไว้ในฐานข้อมูล ตรวจสอบงานนำเสนอนี้

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

ฉันได้เปิดตัวเครื่องมือสำหรับ sqlite ที่ทำในสิ่งที่คุณต้องการ โดยใช้ไดร์เวอร์ diff แบบกำหนดเองซึ่งใช้ประโยชน์จากเครื่องมือโปรเจ็กต์ sqlite 'sqldiff', UUIDs เป็นคีย์หลักและออกจาก rowid ของ sqlite มันยังอยู่ในอัลฟาดังนั้นคำติชมจึงได้รับการชื่นชม

Postgres และ mysql นั้นมีความซับซ้อนกว่าเนื่องจากข้อมูลไบนารีถูกเก็บไว้ในหลาย ๆ ไฟล์และอาจไม่ถูกต้องหากคุณสามารถถ่ายภาพได้

https://github.com/cannadayr/git-sqlite

ฉันคิดว่า X-Istence อยู่ในแนวทางที่ถูกต้อง แต่มีการปรับปรุงอีกเล็กน้อยที่คุณสามารถทำได้กับกลยุทธ์นี้ ขั้นแรกให้ใช้:

$pg_dump --schema ... 

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

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

$pg_dump --table=.. <or> --exclude-table=..

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

หากคุณต้องการสำรองข้อมูลทั้งหมดใน repo ให้ลองทำในสาขานอกแหล่งที่มาของต้นไม้ ระบบสำรองข้อมูลภายนอกที่มีการอ้างอิงถึง svn rev ที่ตรงกันน่าจะเป็นสิ่งที่ดีที่สุดสำหรับสิ่งนี้

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

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

คำถามนี้มีคำตอบสวยมาก แต่ฉันต้องการเติมเต็มคำตอบของ X-Istence และ Dana the Sane ด้วยคำแนะนำเล็ก ๆ

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

ด้วยสิ่งนี้คุณมีทั้งข้อดีของการควบคุมการแก้ไขและคุณไม่ต้องเสียพื้นที่มากเกินไป

ไม่ว่าในกรณีใดการใช้ git โดยตรงกับไฟล์ขนาดใหญ่ที่มีการเปลี่ยนแปลงบ่อยมากไม่ใช่ทางออกที่ดี หากฐานข้อมูลของคุณใหญ่เกินไป git จะเริ่มมีปัญหาในการจัดการไฟล์

นี่คือสิ่งที่ฉันพยายามทำในโครงการของฉัน:

• แยกข้อมูลและสคีมาและข้อมูลเริ่มต้น

การกำหนดค่าฐานข้อมูลจะถูกเก็บไว้ในไฟล์การกำหนดค่าที่ไม่อยู่ภายใต้การควบคุมเวอร์ชัน (.gitignore)

ค่าเริ่มต้นฐานข้อมูล (สำหรับการตั้งค่าโครงการใหม่) เป็นไฟล์ SQL อย่างง่ายภายใต้การควบคุมเวอร์ชัน

สำหรับสกีมาฐานข้อมูลสร้างดัมพ์สกีมาฐานข้อมูลภายใต้การควบคุมเวอร์ชัน

วิธีที่พบมากที่สุดคือการมีสคริปต์การอัพเดทที่มีคำสั่ง SQL (ALTER Table .. หรือ UPDATE) คุณต้องมีสถานที่ในฐานข้อมูลที่คุณบันทึก schema เวอร์ชันปัจจุบันของคุณด้วย)

ลองดูที่โครงการฐานข้อมูลโอเพ่นซอร์สขนาดใหญ่อื่น ๆ (piwik หรือระบบ cms ที่คุณชื่นชอบ) พวกเขาทั้งหมดใช้ updatescripts (1.sql, 2.sql, 3.sh, 4.php.5.sql)

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

ในทางทฤษฎี (และนั่นคือสิ่งที่ฉันกำลังมองหา) คุณสามารถทิ้งสคีมาฐานข้อมูลหลังจากการเปลี่ยนแปลงแต่ละครั้ง (ด้วยตนเอง conjob, git hooks (อาจจะก่อนที่จะกระทำ)) (และในบางกรณีที่พิเศษมากเท่านั้นสร้าง updatecripts)

หลังจากนั้นใน updatescript ทั่วไปของคุณ (เรียกใช้ updatecripts ปกติสำหรับกรณีพิเศษ) แล้วเปรียบเทียบ schemas (การถ่ายโอนข้อมูลและฐานข้อมูลปัจจุบัน) แล้วสร้าง nessesary ALTER Statement โดยอัตโนมัติ มีเครื่องมือบางอย่างที่สามารถทำได้แล้ว แต่ยังไม่พบที่ดี

ฉันอยากจะแนะนำneXtepสำหรับรุ่นที่ควบคุมฐานข้อมูลมันมีชุดเอกสารและฟอรัมที่อธิบายวิธีการติดตั้งและข้อผิดพลาดที่พบ ฉันได้ทดสอบมันสำหรับ postgreSQL 9.1 และ 9.3 ฉันสามารถทำให้มันใช้งานได้สำหรับ 9.1 แต่สำหรับ 9.3 มันดูเหมือนจะไม่ทำงาน

สิ่งที่ฉันทำในโครงการส่วนตัวของฉันคือฉันเก็บฐานข้อมูลทั้งหมดของฉันไปที่ดรอปบ็อกซ์จากนั้นชี้ MAMP เวิร์กโฟลว์ WAMP เพื่อใช้งานได้ทันที .. แต่นั่นก็เพื่อ dev! ไซต์สดกำลังใช้เซิร์ฟเวอร์ของตัวเองสำหรับหลักสูตรนี้! :)

การจัดเก็บการเปลี่ยนแปลงฐานข้อมูลแต่ละระดับภายใต้การควบคุมการกำหนดเวอร์ชัน git ก็เหมือนกับการผลักฐานข้อมูลทั้งหมดของคุณด้วยการกระทำและการกู้คืนฐานข้อมูลทั้งหมดของคุณด้วยการดึงแต่ละครั้ง หากฐานข้อมูลของคุณมีแนวโน้มที่จะเปลี่ยนแปลงอย่างมีนัยสำคัญและคุณไม่สามารถที่จะสูญเสียคุณสามารถอัปเดตpre_commitและpost_merge hooks ของคุณ ผมก็ทำเช่นเดียวกันกับหนึ่งในโครงการของฉันและคุณสามารถหาทิศทางที่นี่

นั่นเป็นวิธีที่ฉันทำ:

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

สร้างเทมเพลต DB ซึ่งมีสคีมาที่เหมาะกับสาขาจริงของคุณและเก็บไว้ในที่เก็บของคุณ

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

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

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

ในแต่ละเครื่องเรามีไฟล์ PHP แต่ยังรวมถึงบริการ MySQL และโฟลเดอร์ที่มีรูปภาพที่ผู้ใช้จะอัปโหลด เซิร์ฟเวอร์ Live มีผู้ใช้ซ้ำอีก 100K (!) การถ่ายโอนข้อมูลอยู่ที่ 2GB (!) โฟลเดอร์ Image มีขนาด 50GB (!) ตามเวลาที่ฉันออกเซิร์ฟเวอร์ของเราถึงขีด จำกัด ของ CPU, Ram และที่สำคัญที่สุดคือข้อ จำกัด การเชื่อมต่อเน็ตที่เกิดขึ้นพร้อมกัน (เรายังรวบรวมไดรเวอร์การ์ดเครือข่ายเวอร์ชั่นของเราเองเพื่อขยายเซิร์ฟเวอร์ 'lol') เราไม่สามารถ ( หรือคุณไม่ควรถือว่าเว็บไซต์ของคุณ ) ใส่ข้อมูล 2GB และรูปภาพ 50GB ใน GIT

ในการจัดการทั้งหมดภายใต้ GIT อย่างง่ายดายเราจะเพิกเฉยต่อโฟลเดอร์ไบนารี (โฟลเดอร์ที่มีรูปภาพ) โดยการแทรกเส้นทางโฟลเดอร์เหล่านี้ลงใน. gitignore นอกจากนี้เรายังมีโฟลเดอร์ชื่อ SQL นอกเส้นทางเอกสาร Apache ในโฟลเดอร์ SQL นั้นเราจะใส่ไฟล์ SQL ของเราจากนักพัฒนาด้วยการเพิ่มตัวเลข (001.florianm.sql, 001.johns.sql, 002.florianm.sql และอื่น ๆ ) ไฟล์ SQL เหล่านี้ได้รับการจัดการโดย GIT เช่นกัน ไฟล์ sql แรกจะมี DB schema ชุดใหญ่แน่นอน เราไม่เพิ่มข้อมูลผู้ใช้ใน GIT (เช่นบันทึกของตารางผู้ใช้หรือตารางความคิดเห็น) แต่ข้อมูลเช่น configs หรือโทโพโลยีหรือข้อมูลเฉพาะไซต์อื่น ๆ นั้นได้รับการปรับปรุงในไฟล์ sql (และด้วย GIT) นักพัฒนาส่วนใหญ่ (ซึ่งรู้จักรหัสดีที่สุด) ซึ่งกำหนดว่าอะไรและสิ่งใดที่ GIT ไม่ได้รับการดูแลเกี่ยวกับ SQL schema และข้อมูล

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

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

วันนี้เรารักษาทั้งโฟลเดอร์ sql-up และ sql-down ที่มีชื่อไฟล์เทียบเท่าซึ่งผู้พัฒนาต้องทดสอบว่าทั้งไฟล์ sql ที่อัพเกรดสามารถอัพเกรดได้เท่า ๆ กัน สิ่งนี้สามารถถูกประหารชีวิตด้วยสคริปต์ทุบตีในที่สุด แต่เป็นความคิดที่ดีถ้าหากสายตาของผู้คนเฝ้าดูกระบวนการอัพเกรด

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

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

สิ่งนี้ช่วยให้คุณสามารถเลือกใช้การเปลี่ยนแปลงส่วนบุคคลกับสภาพแวดล้อมที่แตกต่างกันเก็บรายการเปลี่ยนแปลงที่อยู่ในสภาพแวดล้อมสร้างสคริปต์เพื่อใช้การเปลี่ยนแปลง A ถึง N การเปลี่ยนแปลงย้อนกลับเป็นต้น

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

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

อัปเดต 26 สิงหาคม 2019:

Netlify CMSกำลังทำกับ GitHub ตัวอย่างการใช้งานสามารถพบได้ที่นี่พร้อมข้อมูลทั้งหมดเกี่ยวกับวิธีที่พวกเขาใช้มันnetlify-cms-backend-github