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

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

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

อย่างไรก็ตามฉันรู้ว่าเรื่องราวนั้นเป็นอย่างไร เป็นเพียงเรื่องของเวลาก่อนที่สิ่งต่าง ๆ เข้าแถวผิดและมีบางอย่างหายไป

มีวิธีปฏิบัติที่ดีที่สุดสำหรับสิ่งนี้หรือไม่? กลยุทธ์อะไรบ้างที่ใช้ได้ผลสำหรับคุณ

ต้องอ่านได้รับฐานข้อมูลของคุณภายใต้การควบคุมรุ่น ตรวจสอบชุดของโพสต์โดย K. Scott Allen

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

ฐานข้อมูลตัวเอง? ไม่

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

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

ฉันรัก Rails ActiveRecord อย่างมาก มันทำให้บทคัดย่อ DML เป็น ruby ​​script ซึ่งสามารถเป็น version'd ได้ง่ายในแหล่งเก็บข้อมูลของคุณ

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

Rails ยังมีตาราง 'version' ในฐานข้อมูลที่ติดตามการย้ายข้อมูลที่ใช้ครั้งล่าสุด คุณสามารถทำเช่นเดียวกันได้อย่างง่ายดาย

ลองใช้LiquiBaseเพื่อจัดการการเปลี่ยนแปลงฐานข้อมูลโดยใช้การควบคุมแหล่งที่มา

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

if [ $VERSION \< '8.0.108' ] ; then
  psql -U cosuser $dbName << EOF8.0.108
    BEGIN TRANSACTION;
    --
    -- Remove foreign key that shouldn't have been there.
    -- PCR:35665
    --
    ALTER TABLE     migratorjobitems
    DROP CONSTRAINT migratorjobitems_destcmaid_fkey;
    -- 
    -- Increment the version
    UPDATE          sys_info
    SET             value = '8.0.108'
    WHERE           key = 'DB VERSION';
    END TRANSACTION;
EOF8.0.108
fi

if [ $VERSION \< '8.0.109' ] ; then
  psql -U cosuser $dbName << EOF8.0.109
    BEGIN TRANSACTION;
    --
    -- I missed a couple of cases when I changed the legacy playlist
    -- from reporting showplaylistidnum to playlistidnum
    --
    ALTER TABLE     featureidrequestkdcs
    DROP CONSTRAINT featureidrequestkdcs_cosfeatureid_fkey;
    ALTER TABLE     featureidrequestkdcs
    ADD CONSTRAINT  featureidrequestkdcs_cosfeatureid_fkey
    FOREIGN KEY     (cosfeatureid)
    REFERENCES      playlist(playlistidnum)
    ON DELETE       CASCADE;
    --
    ALTER TABLE     ticket_system_ids
    DROP CONSTRAINT ticket_system_ids_showplaylistidnum_fkey;
    ALTER TABLE     ticket_system_ids
    RENAME          showplaylistidnum
    TO              playlistidnum;
    ALTER TABLE     ticket_system_ids
    ADD CONSTRAINT  ticket_system_ids_playlistidnum_fkey
    FOREIGN KEY     (playlistidnum)
    REFERENCES      playlist(playlistidnum)
    ON DELETE       CASCADE;
    -- 
    -- Increment the version
    UPDATE          sys_info
    SET             value = '8.0.109'
    WHERE           key = 'DB VERSION';
    END TRANSACTION;
EOF8.0.109
fi

ฉันแน่ใจว่ามีวิธีที่ดีกว่าในการทำเช่นนี้ แต่มันก็ใช้ได้สำหรับฉันจนถึงตอนนี้

ใช่. รหัสคือรหัส กฎง่ายๆของฉันคือฉันต้องสามารถสร้างและปรับใช้แอปพลิเคชันตั้งแต่เริ่มต้นโดยไม่ต้องดูที่การพัฒนาหรือการผลิตเครื่องจักร

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

ฉันเชื่อว่าสิ่งนี้ทำได้ด้วย NaNt / CruiseControl

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

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

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

โครงการฐานข้อมูลใหม่ใน Visual Studio ให้การควบคุมแหล่งที่มาและสคริปต์การเปลี่ยนแปลง

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

db schema คือ "shredded" เพื่อสร้างไฟล์. sql จำนวนมากหลายไฟล์หนึ่งไฟล์ต่อคำสั่ง DDL ที่อธิบาย DB

+ ทอม

ข้อมูลเพิ่มเติม 2008-11-30

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

เนื่องจากสคีมาคือ "หั่น" เป็นไฟล์ sql ทำให้การควบคุมซอร์สทำงานได้ดี

หนึ่ง gotcha คือการที่คุณต้องมีความคิดที่แตกต่างเมื่อคุณใช้โครงการ db เครื่องมือมี "db project" ใน VS ซึ่งเป็นเพียง sql บวกฐานข้อมูลท้องถิ่นที่สร้างขึ้นโดยอัตโนมัติซึ่งมี schema และข้อมูลผู้ดูแลระบบอื่น ๆ - แต่ไม่มีข้อมูลแอปพลิเคชันของคุณรวมถึง dev db ในเครื่องที่คุณใช้ แอป data dev ทำงาน คุณไม่ค่อยทราบเกี่ยวกับฐานข้อมูลที่สร้างขึ้นโดยอัตโนมัติ แต่คุณต้องรู้ว่ามันอยู่ที่นั่นเพื่อที่คุณจะได้ทิ้งมันไว้คนเดียว :) ฐานข้อมูลพิเศษนี้เป็นที่รู้จักอย่างชัดเจนเพราะมี Guid ในชื่อ

โครงการ VS DB ทำงานได้อย่างยอดเยี่ยมในการรวมการเปลี่ยนแปลง db ที่สมาชิกในทีมคนอื่น ๆ ได้ทำไว้ในโครงการโลคอล / db ที่เกี่ยวข้อง แต่คุณต้องใช้ขั้นตอนพิเศษเพื่อเปรียบเทียบ schema ของโครงการกับ schema dev db ในพื้นที่ของคุณและใช้ mods มันสมเหตุสมผล แต่ดูเหมือนจะอึดอัดในตอนแรก

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

ฉันชอบโครงการ VS DB และฉันคาดหวังว่าจะใช้เครื่องมือนี้สำหรับโครงการ db ทั้งหมดของฉันในอนาคต

+ ทอม

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

ฉันจะแนะนำให้ใช้ SSMS add-in ที่เรียกว่าApexSQL ควบคุมแหล่งที่มา ช่วยให้นักพัฒนาแผนที่วัตถุฐานข้อมูลได้อย่างง่ายดายด้วยระบบควบคุมแหล่งที่มาผ่านตัวช่วยสร้างโดยตรงจาก SSMS Add-in นั้นรองรับ TFS, Git, Subversion และระบบ SC อื่น ๆ นอกจากนี้ยังมีการสนับสนุนสำหรับการควบคุมแหล่งข้อมูลแบบคงที่

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

คุณสามารถอ่านบทความนี้สำหรับข้อมูลเพิ่มเติม: http://solutioncenter.apexsql.com/sql-source-control-reduce-database-development-time/

ฉันทำได้โดยบันทึกสคริปต์สร้าง / อัพเดตและสคริปต์ที่สร้าง sampledata

ใช่เราทำได้โดยทำให้ SQL ของเราเป็นส่วนหนึ่งของงานสร้างของเรา - เราเก็บ DROP.sql, CREATE.sql, USERS.sql, VALUES.sql และรุ่นควบคุมสิ่งเหล่านี้เพื่อให้เราสามารถเปลี่ยนกลับเป็นเวอร์ชันที่ติดแท็ก

นอกจากนี้เรายังมีงานมดที่สามารถสร้างฐานข้อมูลใหม่ได้ทุกเมื่อที่ต้องการ

นอกจากนี้ SQL จะถูกติดแท็กพร้อมกับซอร์สโค้ดของคุณที่ไปกับมัน

รูปแบบที่ประสบความสำเร็จที่สุดที่ฉันเคยใช้ในโครงการได้รวมการสำรองข้อมูลและไฟล์ SQL ที่แตกต่างกัน โดยทั่วไปเราจะสำรองข้อมูล db ของเราหลังจากทุกรุ่นและทำการดัมพ์ SQL เพื่อให้เราสามารถสร้างสคีมาเปล่า ๆ จากศูนย์ถ้าเราต้องการเช่นกัน จากนั้นเมื่อใดก็ตามที่คุณจำเป็นต้องทำการเปลี่ยนแปลงฐานข้อมูลคุณจะต้องเพิ่มสแครปไปยังไดเรกทอรี sql ภายใต้การควบคุมเวอร์ชัน เราจะใส่คำนำหน้าหมายเลขลำดับหรือวันที่ในชื่อไฟล์เสมอดังนั้นการเปลี่ยนแปลงครั้งแรกจะเป็นสิ่งที่ต้องการเช่น 01_add_created_on_column.sql และสคริปต์ถัดไปจะเป็น 02_added_customers_index เครื่อง CI ของเราจะตรวจสอบสิ่งเหล่านี้และรันตามลำดับบนสำเนาใหม่ของฐานข้อมูลที่ได้รับการกู้คืนจากข้อมูลสำรอง

นอกจากนี้เรายังมีสคริปต์บางส่วนที่ devs สามารถใช้เพื่อเริ่มต้น db โลคัลใหม่เป็นเวอร์ชันปัจจุบันโดยใช้คำสั่งเดียว

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

ฉันใช้SchemaBankเป็นเวอร์ชันควบคุมการเปลี่ยนแปลงคีมาฐานข้อมูลของฉันทั้งหมด:

• ตั้งแต่วันที่ 1 ฉันนำเข้าดัมพ์สกีมา db ของฉันลงไป
• ฉันเริ่มเปลี่ยนการออกแบบสคีมาของฉันโดยใช้เว็บเบราว์เซอร์ (เพราะเป็น SaaS / cloud-based)
• เมื่อฉันต้องการอัพเดทเซิร์ฟเวอร์ db ของฉันฉันสร้างสคริปต์การเปลี่ยนแปลง (SQL) จากนั้นและนำไปใช้กับ db ใน Schemabank พวกเขาสั่งให้ฉันมอบหมายงานของฉันเป็นเวอร์ชันก่อนที่ฉันจะสามารถสร้างสคริปต์อัปเดตได้ ฉันชอบการฝึกฝนแบบนี้เพื่อที่ฉันจะได้ย้อนกลับไปเมื่อฉันต้องการ

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

โดยวิธีการพวกเขายังให้เราสร้างสาขาภายในต้นไม้ควบคุมเวอร์ชันเพื่อให้ฉันสามารถรักษาหนึ่งสำหรับการแสดงละครและหนึ่งสำหรับการผลิต และอีกหนึ่งรหัสสำหรับ sandbox

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

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

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

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

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

ฉันใช้สคริปต์ SQL CREATE ที่ส่งออกจาก MySQL Workbech จากนั้นใช้ฟังก์ชั่น "ส่งออก SQL ALTER" ของพวกเขาฉันจบด้วยชุดของสคริปต์สร้าง (จำนวนแน่นอน) และสคริปต์เปลี่ยนที่สามารถใช้การเปลี่ยนแปลงระหว่างพวกเขา

3.- ส่งออกสคริปต์ SQL ALTER โดยปกติแล้วคุณจะต้องเขียนคำสั่ง ALTER TABLE ด้วยมือตอนนี้เพื่อสะท้อนการเปลี่ยนแปลงที่คุณทำกับโมเดล แต่คุณสามารถฉลาดและปล่อยให้ Workbench ทำงานหนักสำหรับคุณ เพียงเลือกไฟล์ -> ส่งออก -> ส่งต่อ SQL Server Alter Script ... จากเมนูหลัก

สิ่งนี้จะแจ้งให้คุณระบุไฟล์ SQL CREATE ที่ควรเปรียบเทียบกับโมเดลปัจจุบัน

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

คุณสามารถทำได้โดยใช้ MySQL Query Browser หรือ mysql client.Voila! โมเดลและฐานข้อมูลของคุณถูกซิงโครไนซ์แล้ว!

ที่มา: MySQL Workbench Community Edition: คู่มือการทำข้อมูลให้ตรงกันแบบแผน

แน่นอนว่าสคริปต์ทั้งหมดนี้อยู่ภายใต้การควบคุมเวอร์ชัน

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

มีการถกเถียงกันมากมายเกี่ยวกับตัวแบบฐานข้อมูล แต่เราก็เก็บข้อมูลที่ต้องการไว้ในไฟล์. SQL

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

INSERT INTO Currency (CurrencyCode, CurrencyName) 
VALUES ('AUD', 'Australian Dollars');

INSERT INTO Currency (CurrencyCode, CurrencyName) 
VALUES ('USD', 'US Dollars');

เราจะมีไฟล์ที่เรียกว่าcurrency.sqlภายใต้การโค่นล้ม เป็นขั้นตอนที่ต้องทำด้วยตนเองในกระบวนการสร้างเราเปรียบเทียบสกุลเงินก่อนหน้านี้กับสกุลเงินล่าสุดและเขียนสคริปต์อัพเกรด

เรามีเวอร์ชั่นและแหล่งที่มาควบคุมทุกสิ่งรอบ ๆ ฐานข้อมูลของเรา:

• DDL (สร้างและเปลี่ยนแปลง)
• DML (ข้อมูลอ้างอิงรหัส ฯลฯ )
• การเปลี่ยนแปลงตัวแบบข้อมูล (โดยใช้ ERwin หรือ ER / Studio)
• การเปลี่ยนแปลงการกำหนดค่าฐานข้อมูล (สิทธิ์วัตถุความปลอดภัยการเปลี่ยนแปลงการกำหนดค่าทั่วไป)

เราทำสิ่งนี้กับงานอัตโนมัติโดยใช้ Change Manager และสคริปต์ที่กำหนดเอง เรามีผู้จัดการการเปลี่ยนแปลงตรวจสอบการเปลี่ยนแปลงเหล่านี้และแจ้งเตือนเมื่อเสร็จ

ฉันเชื่อว่า DB ทุกตัวควรอยู่ภายใต้การควบคุมของแหล่งข้อมูลและนักพัฒนาควรมีวิธีที่ง่ายในการสร้างฐานข้อมูลท้องถิ่นของพวกเขาตั้งแต่เริ่มต้น ได้รับแรงบันดาลใจจาก Visual Studio สำหรับผู้เชี่ยวชาญด้านฐานข้อมูลฉันได้สร้างเครื่องมือโอเพนซอร์ซที่สคริปต์ฐานข้อมูล MS SQL และมอบวิธีที่ง่ายในการปรับใช้กับเครื่องมือฐานข้อมูลท้องถิ่นของคุณ ลองhttp://dbsourcetools.codeplex.com/ ขอให้สนุก - นาธาน

หากฐานข้อมูลของคุณคือ SQL Server เราอาจมีโซลูชันที่คุณต้องการ SQL Source Control 1.0 ได้รับการเผยแพร่แล้ว

http://www.red-gate.com/products/SQL_Source_Control/index.htm

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

โซลูชัน Visual Studio ทางเลือกคือReadyRollซึ่งมีการนำมาใช้เป็นประเภทย่อยของโครงการฐานข้อมูล SSDT วิธีนี้ใช้วิธีการที่ขับเคลื่อนด้วยการย้ายข้อมูลซึ่งเหมาะกับความต้องการระบบอัตโนมัติของทีม DevOps มากขึ้น

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

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

มีการทดสอบมากมายแล้วก่อนที่สคริปต์จะทำงานในสภาพแวดล้อมจริงดังนั้น "oopsies" จะเกิดขึ้นโดยทั่วไปแล้วเท่านั้นที่พูดในฐานข้อมูลการพัฒนา

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

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

ขอให้โชคดีกับคุณมากยิ่งคุณทดลองใช้งานเร็วเท่าไหร่คุณก็ยิ่งประสบปัญหาของคุณมากขึ้นเท่านั้น

ฉันได้ใช้เครื่องมือ dbdeploy จาก ThoughtWorks ที่http://dbdeploy.com/ มันสนับสนุนการใช้สคริปต์การโยกย้าย แต่ละรุ่นเรารวมสคริปต์การเปลี่ยนแปลงไว้ในไฟล์เดียวเพื่อให้เข้าใจง่ายและอนุญาตให้ DBAs 'อวยพร' การเปลี่ยนแปลง

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

เครื่องมือที่ฉันเคยใช้ในอดีตที่ช่วยด้วยบางอย่างนี้คือ SQL Delta มันจะแสดงความแตกต่างระหว่างสองฐานข้อมูล (เซิร์ฟเวอร์ SQL / Oracle ฉันเชื่อว่า) และสร้างสคริปต์การเปลี่ยนแปลงทั้งหมดที่จำเป็นในการโยกย้าย A-> B สิ่งที่ดีอีกอย่างหนึ่งก็คือแสดงความแตกต่างทั้งหมดระหว่างเนื้อหาฐานข้อมูลระหว่างฐานข้อมูลการผลิต (หรือทดสอบ) และฐานข้อมูลการพัฒนาของคุณ เนื่องจากแอปจำนวนมากเก็บการกำหนดค่าและสถานะที่สำคัญต่อการเรียกใช้งานในตารางฐานข้อมูลจึงเป็นเรื่องยากที่จะมีสคริปต์การเปลี่ยนแปลงที่ลบเพิ่มและแก้ไขแถวที่เหมาะสม SQL Delta แสดงแถวในฐานข้อมูลเหมือนกับที่พวกเขามองในเครื่องมือ Diff - เปลี่ยนแปลงเพิ่มลบออก

เครื่องมือที่ยอดเยี่ยม นี่คือลิงค์: http://www.sqldelta.com/

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

RedGate ยังสร้าง snapshot ของข้อมูลในขณะที่ฉันไม่ได้ทำงานกับพวกเขาเป็นการส่วนตัวที่แข็งแกร่ง

FYI สิ่งนี้ถูกนำขึ้นมาเมื่อไม่กี่วันที่ผ่านมาโดย Dana ... ขั้นตอนการจัดเก็บ / สคีมา DB ในการควบคุมแหล่งที่มา