การเปรียบเทียบและการเลือกระบบการย้ายข้อมูล

การเปรียบเทียบและการเลือกระบบการย้ายข้อมูล

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

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

งาน

ปัจจุบันบริษัทของเรากำลังพัฒนาผลิตภัณฑ์เจเนอเรชันถัดไปอย่างแข็งขัน – Docs Security Suite (DSS) ส่วนเซิร์ฟเวอร์เขียนด้วย .Net Core และ Entity Framework Core ใช้เป็น DBMS เมื่อออกแบบแอปพลิเคชัน เราใช้แนวทาง Code First

โมเดลโดเมนแอปพลิเคชันถูกสร้างขึ้นโดยนักพัฒนาหลายคนในเวลาเดียวกัน - แต่ละคนมีหน้าที่รับผิดชอบในส่วนตรรกะของระบบของตนเอง

DSS รุ่นก่อนหน้าใช้ Entity Framework Migrations (EF 6) แบบคลาสสิกเป็นระบบจัดการการย้าย อย่างไรก็ตาม มีการร้องเรียนบางส่วนเกิดขึ้น ประเด็นหลักคือ EF ขาดแนวทางที่สมเหตุสมผลในการแก้ไขข้อขัดแย้งของเวอร์ชัน ข้อเท็จจริงนี้ยังคงทำให้เราไม่พอใจเมื่อแก้ไขข้อบกพร่องซึ่งเป็นส่วนหนึ่งของการสนับสนุน ดังนั้นเราจึงตัดสินใจพิจารณาทางเลือกอื่น

จากการอภิปราย ทำให้เกิดข้อกำหนดต่อไปนี้สำหรับระบบการจัดการการย้ายถิ่นฐาน:

1. รองรับ DBMS ต่างๆ จำเป็นต้องใช้ MS SQL Server, PostgreSQL, Oracle แต่อาจเป็นไปได้ที่จะใช้โปรแกรมอื่น
2. ร่วมงานกับ ออม. ในตอนแรกมีแผนจะใช้ EF Core แต่ในขั้นตอนการออกแบบ เราก็พร้อมที่จะพิจารณา ORM อื่นๆ
3. การสร้างการโยกย้ายอัตโนมัติ เมื่อคำนึงถึงการพัฒนา Code First ฉันต้องการหลีกเลี่ยงความจำเป็นในการโยกย้าย "เขียนด้วยมือ"
4. ข้อขัดแย้งของเวอร์ชัน ในสภาพแวดล้อมการพัฒนาแบบกระจาย เมื่อรวมเข้าด้วยกัน EF Core อาจประสบปัญหาข้อขัดแย้ง สิ่งนี้กลายเป็นปัญหาสำคัญเนื่องจากส่วนต่าง ๆ ของแอปพลิเคชันถูกสร้างขึ้นโดยนักพัฒนาที่แตกต่างกัน ดังนั้นคุณจึงต้องใช้เวลามากกับแต่ละส่วน
5. เอกสารและการสนับสนุนขั้นสูง สำหรับเราที่นี่ดูเหมือนว่าไม่ต้องการคำอธิบาย
6. ฟรี. เกณฑ์เป็นไปตามเงื่อนไข เนื่องจากระบบไม่แพงมากหรือแพง แต่เหมาะในเรื่องความสะดวกสบาย เราจึงพร้อมที่จะพิจารณาด้วย

จากการวิจัยเพียงเล็กน้อย พบว่ามีตัวเลือกต่อไปนี้และน่าพิจารณา:

1. การโยกย้ายหลักของ EF
2. ดีบีอัพ
3. ราวด์เฮาส์E
4. ThinkingHome ผู้อพยพ
5. ผู้อพยพที่คล่องแคล่ว

และตอนนี้มีรายละเอียดเพิ่มเติมเล็กน้อย

การย้ายข้อมูลหลักของ EntityFramework

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

ดังนั้นจึงเน้นถึงข้อดีของ EF Core:

• การสนับสนุนของ Microsoft เอกสารประกอบ รวมถึงภาษารัสเซีย ชุมชนขนาดใหญ่
• การสร้างการโยกย้ายอัตโนมัติตาม CodeFirst
• เมื่อเปรียบเทียบกับ EF 6 แล้ว EF Core จะไม่จัดเก็บสแน็ปช็อตของฐานข้อมูลอีกต่อไป เมื่อทำงานกับ EF Core ใน Code First ไม่จำเป็นต้องปรับใช้ฐานข้อมูลอีกต่อไป
• เนื่องจากเรากำลังเต้นจาก Code First จึงเป็นไปได้ที่จะดำเนินการโอนย้ายไปยังผู้ให้บริการการเข้าถึงข้อมูลที่จำเป็นทั้งหมด
• ในส่วนของผู้ให้บริการนั้น รองรับ PostgreSQL, รองรับ Oracle ฯลฯ ฯลฯ และแม้แต่ MS SQL Server 

และยังมีข้อเสีย:

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

ดีบีอัพ

dbup.github.io

DbUp เป็นไลบรารี .NET ที่ติดตั้งโดย NuGet และช่วยผลักดันการเปลี่ยนแปลงไปยัง SQL Server โดยจะติดตามว่าสคริปต์การเปลี่ยนแปลงใดบ้างที่ได้ดำเนินการไปแล้ว และเรียกใช้สคริปต์การเปลี่ยนแปลงที่จำเป็นในการอัปเดตฐานข้อมูล ไลบรารีนี้เติบโตจากโปรเจ็กต์สำหรับเอ็นจิ้นการเขียนบล็อกโอเพ่นซอร์สบน ASP.NET และอยู่ภายใต้ใบอนุญาต MIT และโค้ดอยู่บน GitHub การย้ายข้อมูลอธิบายโดยใช้ T-SQL

ข้อดีคืออะไร:

• รองรับ DBMS จำนวนมาก (MS SQL Server, PstgreSQL, MySQL)
• เนื่องจากสคริปต์เขียนด้วย T-SQL จึงดูค่อนข้างเรียบง่าย
• ข้อขัดแย้งได้รับการแก้ไขโดยใช้ SQL

และข้อเสีย:

• ด้วย DBMS ที่รองรับที่หลากหลาย Oracle ไม่ใช่หนึ่งในนั้น
• ไม่โต้ตอบกับ ORM
• การเขียนสคริปต์ T-SQL ด้วยมือไม่ใช่สิ่งที่เราตั้งเป้าไว้
• เอกสารประกอบและชุมชนก็พอใช้ได้ แม้ว่าในแง่ของการเขียนสคริปต์ SQL อาจไม่จำเป็นก็ตาม

ราวด์เฮาส์E

github.com/chucknorris/roundhouse

เครื่องมือการจัดการการย้ายข้อมูลนี้เผยแพร่ภายใต้ใบอนุญาต Apache 2.0 เช่นเดียวกับเวอร์ชันก่อนหน้า ทำงานบนกลไกการย้ายข้อมูล T-SQL เห็นได้ชัดว่านักพัฒนาให้ความสำคัญกับการแก้ปัญหาทางเทคนิคที่เกี่ยวข้องกับการสนับสนุน DBMS มากกว่าการสร้างกระบวนการพัฒนาที่สะดวกสบาย

จุดเด่น:

• รองรับ DBMS ที่จำเป็น (รวมถึง Oracle)

จุดด้อย:

• Oracle (รวมถึง Access ซึ่งไม่เกี่ยวข้องกับเรา) ไม่ได้รับการสนับสนุนบน .NET Core เฉพาะบน .NET Full Framework เท่านั้น
• ใช้ไม่ได้กับ ORM
• มีเอกสารประกอบน้อยกว่าเครื่องมือก่อนหน้านี้ด้วยซ้ำ
• อีกครั้ง – การโยกย้ายถูกเขียนโดยสคริปต์

ThinkingHome ผู้อพยพ

เครื่องมือสำหรับการย้ายสคีมาฐานข้อมูลตามเวอร์ชันไปยังแพลตฟอร์ม .NET Core ซึ่งเผยแพร่ภายใต้ใบอนุญาต MIT นักพัฒนาเองเขียนเกี่ยวกับเวอร์ชันล่าสุดเมื่อเกือบหนึ่งปีที่แล้ว.

จุดเด่น:

• ออกแบบมาสำหรับ .NET Core
• ใช้ลำดับการแตกแขนงของการโยกย้าย
• ดำเนินการบันทึกการโยกย้าย

จุดด้อย:

• อัปเดตล่าสุดเมื่อปีที่แล้ว เห็นได้ชัดว่าโครงการนี้ไม่ได้รับการสนับสนุน
• ไม่รองรับโดย Oracle (บทความระบุว่านี่เป็นเพราะขาดการใช้งานที่เสถียรสำหรับ .NET Core - แต่นี่คือปีที่แล้ว)
• ไม่มีการสร้างการโยกย้ายอัตโนมัติ

โดยรวมแล้ว โครงการนี้ดูมีแนวโน้มดี โดยเฉพาะอย่างยิ่งหากต้องพัฒนา แต่เราจำเป็นต้องตัดสินใจที่นี่และเดี๋ยวนี้

ผู้อพยพที่คล่องแคล่ว

github.com/fluentmigrator/fluentmigrator

เครื่องมือการโยกย้ายที่ได้รับความนิยมสูงสุดพร้อมกองทัพแฟน ๆ จำนวนมาก เผยแพร่ภายใต้ลิขสิทธิ์ Apache 2.0 ตามที่ระบุไว้ในคำอธิบาย มันเป็นเฟรมเวิร์กการย้ายสำหรับ .NET คล้ายกับ Ruby on Rails Migrations การเปลี่ยนแปลงสคีมาฐานข้อมูลอธิบายไว้ในคลาส C#

มีข้อดีอยู่ที่นี่:

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

สำหรับข้อเสียมีดังนี้:

• ไม่มีการสร้างการโยกย้ายอัตโนมัติ
• ไม่มีการเชื่อมต่อกับรุ่น EF
• ไม่มีสแน็ปช็อตฐานข้อมูล

เราเลือกอะไร?

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

ผลการวิจัย

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

ที่มา: will.com