ການປຽບທຽບແລະການຄັດເລືອກລະບົບການເຄື່ອນຍ້າຍຂໍ້ມູນ

ການປຽບທຽບແລະການຄັດເລືອກລະບົບການເຄື່ອນຍ້າຍຂໍ້ມູນ

ຮູບແບບຂໍ້ມູນມີແນວໂນ້ມທີ່ຈະປ່ຽນແປງໃນລະຫວ່າງຂະບວນການພັດທະນາ, ແລະໃນບາງຈຸດມັນບໍ່ກົງກັບຖານຂໍ້ມູນ. ແນ່ນອນ, ຖານຂໍ້ມູນສາມາດຖືກລຶບ, ແລະຫຼັງຈາກນັ້ນ ORM ຈະສ້າງສະບັບໃຫມ່ທີ່ຈະກົງກັບຮູບແບບ, ແຕ່ຂັ້ນຕອນນີ້ຈະນໍາໄປສູ່ການສູນເສຍຂໍ້ມູນທີ່ມີຢູ່. ດັ່ງນັ້ນ, ຫນ້າທີ່ຂອງລະບົບການເຄື່ອນຍ້າຍແມ່ນເພື່ອໃຫ້ແນ່ໃຈວ່າ, ເປັນຜົນມາຈາກການປ່ຽນແປງ schema, ມັນຖືກ synchronized ກັບຮູບແບບຂໍ້ມູນໃນຄໍາຮ້ອງສະຫມັກໂດຍບໍ່ມີການສູນເສຍຂໍ້ມູນທີ່ມີຢູ່ແລ້ວ.

ໃນບົດຄວາມນີ້, ພວກເຮົາຢາກຈະເບິ່ງເຄື່ອງມືຕ່າງໆສໍາລັບການຄຸ້ມຄອງການເຄື່ອນຍ້າຍຖານຂໍ້ມູນ. ພວກເຮົາຫວັງວ່າການທົບທວນຄືນນີ້ຈະເປັນປະໂຫຍດສໍາລັບນັກພັດທະນາທີ່ປະເຊີນຫນ້າກັບທາງເລືອກທີ່ຄ້າຍຄືກັນ.

ຈຸດປະສົງ

ບໍລິສັດຂອງພວກເຮົາກຳລັງພັດທະນາຜະລິດຕະພັນລຸ້ນຕໍ່ໄປຢ່າງຫ້າວຫັນ – Docs Security Suite (DSS). ສ່ວນເຊີບເວີແມ່ນຂຽນໃນ .Net Core, ແລະ Entity Framework Core ຖືກໃຊ້ເປັນ DBMS. ເມື່ອອອກແບບແອັບພລິເຄຊັນ, ພວກເຮົາໃຊ້ວິທີ Code First.

ຮູບແບບໂດເມນຂອງແອັບພລິເຄຊັນຖືກສ້າງຂື້ນໂດຍນັກພັດທະນາຫຼາຍໆຄົນໃນເວລາດຽວກັນ - ແຕ່ລະຄົນມີຄວາມຮັບຜິດຊອບຕໍ່ສ່ວນທີ່ມີເຫດຜົນຂອງຕົນເອງຂອງລະບົບ.

ລຸ້ນກ່ອນໜ້າຂອງ DSS ໃຊ້ Entity Framework Migrations ຄລາສສິກ (EF 6) ເປັນລະບົບການຈັດການການເຄື່ອນຍ້າຍ. ຢ່າງໃດກໍຕາມ, ບາງຄໍາຮ້ອງທຸກໄດ້ສະສົມຕໍ່ກັບມັນ, ຕົ້ນຕໍແມ່ນວ່າ EF ຂາດວິທີການທີ່ສົມເຫດສົມຜົນເພື່ອແກ້ໄຂຂໍ້ຂັດແຍ່ງສະບັບ. ຄວາມຈິງນີ້ຍັງເຮັດໃຫ້ພວກເຮົາ upsets ໃນເວລາທີ່ແກ້ໄຂຂໍ້ບົກຜ່ອງເປັນສ່ວນຫນຶ່ງຂອງການສະຫນັບສະຫນູນ, ດັ່ງນັ້ນພວກເຮົາໄດ້ຕັດສິນໃຈພິຈາລະນາທາງເລືອກອື່ນ.

ຈາກ​ຜົນ​ຂອງ​ການ​ສົນ​ທະ​ນາ, ຂໍ້​ກໍາ​ນົດ​ຕໍ່​ໄປ​ນີ້​ສໍາ​ລັບ​ລະ​ບົບ​ການ​ຄຸ້ມ​ຄອງ​ການ​ເຄື່ອນ​ຍ້າຍ​ໄດ້​ຖືກ​ສ້າງ​ຕັ້ງ​ຂຶ້ນ​:

1. ຮອງຮັບ DBMSs ຕ່າງໆ. MS SQL Server, PostgreSQL, Oracle ແມ່ນຕ້ອງການ, ແຕ່ມີທ່າແຮງທີ່ຈະໃຊ້ຄົນອື່ນ
2. ເຮັດວຽກກັບ ORM. ໃນເບື້ອງຕົ້ນ, ມັນໄດ້ຖືກວາງແຜນທີ່ຈະໃຊ້ EF Core, ແຕ່ໃນຂັ້ນຕອນການອອກແບບພວກເຮົາພ້ອມທີ່ຈະພິຈາລະນາ ORMs ອື່ນໆ.
3. ການຜະລິດອັດຕະໂນມັດຂອງການເຄື່ອນຍ້າຍ. ຄໍານຶງເຖິງການພັດທະນາຂອງລະຫັດທໍາອິດ, ຂ້າພະເຈົ້າຕ້ອງການທີ່ຈະຫຼີກເວັ້ນຄວາມຕ້ອງການທີ່ຈະ "ຂຽນດ້ວຍມື" ການເຄື່ອນຍ້າຍ.
4. ສະບັບຂັດກັນ. ໃນສະພາບແວດລ້ອມການພັດທະນາທີ່ແຈກຢາຍ, ເມື່ອປະສົມປະສານ, EF Core ສາມາດທົນທຸກຈາກການຂັດແຍ້ງ. ນີ້ກາຍເປັນບັນຫາທີ່ສໍາຄັນເພາະວ່າພາກສ່ວນຕ່າງໆຂອງຄໍາຮ້ອງສະຫມັກແມ່ນສ້າງຂື້ນໂດຍນັກພັດທະນາທີ່ແຕກຕ່າງກັນ, ດັ່ງນັ້ນທ່ານຕ້ອງໃຊ້ເວລາຫຼາຍໃນແຕ່ລະຄັ້ງ.
5. ເອກະສານຂັ້ນສູງ ແລະການຊ່ວຍເຫຼືອ. ທີ່ນີ້, ມັນເບິ່ງຄືວ່າພວກເຮົາ, ບໍ່ມີຄໍາອະທິບາຍທີ່ຈໍາເປັນ
6. ຟຣີ. ເງື່ອນໄຂແມ່ນເງື່ອນໄຂ, ເພາະວ່າລະບົບບໍ່ແພງຫຼາຍຫຼືລາຄາແພງ, ແຕ່ເຫມາະສົມໃນຄວາມສະດວກສະບາຍ, ພວກເຮົາຍັງພ້ອມທີ່ຈະພິຈາລະນາ.

ເປັນຜົນມາຈາກການຄົ້ນຄວ້າເລັກນ້ອຍ, ທາງເລືອກຕໍ່ໄປນີ້ໄດ້ຖືກພົບເຫັນແລະເຫັນວ່າສົມຄວນສໍາລັບການພິຈາລະນາ:

1. EF Core Migrations
2. DBup
3. RoundhouseE
4. ThinkingHome.Migrator
5. ເຄື່ອນຍ້າຍທີ່ຄ່ອງແຄ້ວ

ແລະຕອນນີ້ມີລາຍລະອຽດເພີ່ມເຕີມເລັກນ້ອຍ

ການເຄື່ອນຍ້າຍຫຼັກຂອງ EntityFramework

ຕາມທໍາມະຊາດ, ນີ້ແມ່ນທາງເລືອກທໍາອິດແລະຕົ້ນຕໍທີ່ຈະເລືອກເອົາ. ເຄື່ອງ​ມື​ພື້ນ​ເມືອງ​ທີ່​ເຮັດ​ວຽກ​ອອກ​ຈາກ​ປ່ອງ​ໂດຍ​ບໍ່​ມີ​ການ fiddling ມີ tambourine ໄດ້​. ຈໍານວນຂະຫນາດໃຫຍ່ຂອງເອກະສານ, ຢ່າງເປັນທາງການແລະບໍ່ດັ່ງນັ້ນ, ຄວາມງ່າຍດາຍ, ແລະອື່ນໆ. ຢ່າງໃດກໍ່ຕາມ, ຄໍາຮ້ອງທຸກກ່ຽວກັບ EF ຄລາສສິກກໍ່ມີຄວາມກ່ຽວຂ້ອງກັບ EF Core.

ດັ່ງນັ້ນ, ຂໍ້ດີສໍາລັບ EF Core ແມ່ນເນັ້ນໃຫ້ເຫັນ:

• ສະຫນັບສະຫນູນ Microsoft, ເອກະສານ, ລວມທັງພາສາລັດເຊຍ, ຊຸມຊົນຂະຫນາດໃຫຍ່
• ການຜະລິດອັດຕະໂນມັດຂອງການເຄື່ອນຍ້າຍໂດຍອີງໃສ່ CodeFirst
• ເມື່ອປຽບທຽບກັບ EF 6, EF Core ບໍ່ເກັບພາບຖ່າຍຂອງຖານຂໍ້ມູນອີກຕໍ່ໄປ. ເມື່ອເຮັດວຽກກັບ EF Core ໃນລະຫັດທໍາອິດ, ມັນບໍ່ຈໍາເປັນຕ້ອງໃຊ້ຖານຂໍ້ມູນອີກຕໍ່ໄປ
• ເນື່ອງຈາກພວກເຮົາກໍາລັງເຕັ້ນລໍາຈາກ Code First, ມັນເປັນໄປໄດ້ທີ່ຈະດໍາເນີນການໂອນຫນຶ່ງໄປຫາຜູ້ໃຫ້ບໍລິການເຂົ້າເຖິງຂໍ້ມູນທີ່ຕ້ອງການທັງຫມົດ
• ກ່ຽວກັບຜູ້ໃຫ້ບໍລິການ, PostgreSQL ໄດ້ຮັບການສະຫນັບສະຫນູນ, Oracle ແມ່ນສະຫນັບສະຫນູນ, ແລະອື່ນໆ, ແລະອື່ນໆ, ແລະແມ້ກະທັ້ງ MS SQL Server 

ແລະ​ຂໍ້​ເສຍ​ຍັງ​:

• ການແກ້ໄຂຂໍ້ຂັດແຍ່ງຍັງຄົງຢູ່ໃນລະດັບດຽວກັນ. ມັນເປັນສິ່ງຈໍາເປັນເພື່ອຈັດລໍາດັບການເຄື່ອນຍ້າຍແລະປັບປຸງຮູບພາບຂອງຖານຂໍ້ມູນ
• ຂຶ້ນກັບຕົວແບບທີ່ການເຄື່ອນຍ້າຍແມ່ນສ້າງຂຶ້ນ

DbUp

dbup.github.io

DbUp ເປັນຫ້ອງສະຫມຸດ .NET ທີ່ຕິດຕັ້ງໂດຍ NuGet ແລະຊ່ວຍຊຸກຍູ້ການປ່ຽນແປງໃຫ້ກັບ SQL Server. ມັນຕິດຕາມວ່າການປ່ຽນແປງສະຄິບໃດໄດ້ຖືກປະຕິບັດແລ້ວແລະດໍາເນີນການທີ່ຈໍາເປັນເພື່ອປັບປຸງຖານຂໍ້ມູນ. ຫ້ອງສະຫມຸດໄດ້ເຕີບໂຕອອກຈາກໂຄງການສໍາລັບເຄື່ອງຈັກ blogging ແຫຼ່ງເປີດໃນ ASP.NET ແລະມີຢູ່ພາຍໃຕ້ໃບອະນຸຍາດ MIT, ແລະລະຫັດແມ່ນຢູ່ໃນ GitHub. ການເຄື່ອນຍ້າຍແມ່ນອະທິບາຍໂດຍໃຊ້ T-SQL.

ຂໍ້ດີແມ່ນຫຍັງ:

• ຮອງຮັບ DBMS ຈໍານວນຫລາຍ (MS SQL Server, PstgreSQL, MySQL)
• ນັບຕັ້ງແຕ່ສະຄິບຖືກຂຽນໃນ T-SQL, ພວກມັນເບິ່ງຂ້ອນຂ້າງງ່າຍດາຍ
• ການຂັດແຍ້ງຍັງຖືກແກ້ໄຂໂດຍໃຊ້ SQL

ແລະຂໍ້ເສຍ:

• ດ້ວຍຄວາມຫລາກຫລາຍຂອງ DBMSs ທີ່ສະຫນັບສະຫນູນ, Oracle ບໍ່ແມ່ນຫນຶ່ງໃນນັ້ນ
• ບໍ່ມີປະຕິກິລິຍາກັບ ORM
• ການຂຽນສະຄິບ T-SQL ດ້ວຍມືບໍ່ແມ່ນສິ່ງທີ່ພວກເຮົາມຸ່ງຫວັງ
• ເອກະສານແລະຊຸມຊົນແມ່ນຄືກັນ, ເຖິງແມ່ນວ່າໃນການຂຽນ SQL scripts ພວກເຂົາອາດຈະບໍ່ຈໍາເປັນ.

RoundhouseE

github.com/chucknorris/roundhouse

ເຄື່ອງມືການຈັດການການເຄື່ອນຍ້າຍນີ້, ແຈກຢາຍພາຍໃຕ້ໃບອະນຸຍາດ Apache 2.0, ເຊັ່ນດຽວກັບອັນທີ່ຜ່ານມາ, ເຮັດວຽກຢູ່ໃນເຄື່ອງຈັກການເຄື່ອນຍ້າຍ T-SQL. ປາກົດຂື້ນ, ນັກພັດທະນາໄດ້ໃຫ້ຄວາມສໍາຄັນໃນການແກ້ໄຂບັນຫາດ້ານວິຊາການກ່ຽວກັບການສະຫນັບສະຫນູນ DBMS, ແທນທີ່ຈະສ້າງຂະບວນການພັດທະນາທີ່ສະດວກສະບາຍ.

Pros:

• ຮອງຮັບ DBMS ທີ່ຈໍາເປັນ (ລວມທັງ Oracle)

Cons:

• Oracle (ເຊັ່ນດຽວກັນກັບ Access, ທີ່ບໍ່ກ່ຽວຂ້ອງສໍາລັບພວກເຮົາ) ບໍ່ຮອງຮັບໃນ .NET Core, ພຽງແຕ່ຢູ່ໃນ .NET Full Framework ເທົ່ານັ້ນ.
• ໃຊ້ບໍ່ໄດ້ກັບ ORM
• ມີເອກະສານເຖິງແມ່ນວ່າຫນ້ອຍກ່ວາເຄື່ອງມືທີ່ຜ່ານມາ
• ອີກເທື່ອຫນຶ່ງ - ການເຄື່ອນຍ້າຍແມ່ນຂຽນໂດຍສະຄິບ

ThinkingHome.Migrator

ເຄື່ອງມືສຳລັບການເຄື່ອນຍ້າຍແບບແຜນຖານຂໍ້ມູນແບບສະບັບໄປຫາແພລດຟອມ .NET Core, ແຈກຢາຍພາຍໃຕ້ໃບອະນຸຍາດ MIT. ນັກພັດທະນາເອງໄດ້ຂຽນກ່ຽວກັບສະບັບຫລ້າສຸດຂອງຕົນເກືອບຫນຶ່ງປີກ່ອນຫນ້ານີ້.

Pros:

• ອອກແບບສໍາລັບ .NET Core
• ປະຕິບັດການແບ່ງຂັ້ນໄດຂອງການເຄື່ອນຍ້າຍ
• ປະຕິບັດການບັນທຶກການເຄື່ອນຍ້າຍ

Cons:

• ອັບເດດຫຼ້າສຸດເມື່ອໜຶ່ງປີກ່ອນ. ປາກົດຂື້ນວ່າໂຄງການບໍ່ໄດ້ຮັບການສະຫນັບສະຫນູນ
• ບໍ່ໄດ້ຮັບການສະຫນັບສະຫນູນຈາກ Oracle (ບົດຄວາມກ່າວວ່ານີ້ແມ່ນຍ້ອນການຂາດການປະຕິບັດທີ່ຫມັ້ນຄົງສໍາລັບ .NET Core - ແຕ່ນີ້ແມ່ນຫນຶ່ງປີກ່ອນຫນ້ານີ້)
• ບໍ່ມີການຜະລິດອັດຕະໂນມັດຂອງການເຄື່ອນຍ້າຍ

ໂດຍລວມແລ້ວ, ໂຄງການເບິ່ງຄືວ່າມີແນວໂນ້ມ, ໂດຍສະເພາະຖ້າມັນພັດທະນາ, ແຕ່ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ຕັດສິນໃຈຢູ່ທີ່ນີ້ແລະໃນປັດຈຸບັນ.

ເຄື່ອນຍ້າຍທີ່ຄ່ອງແຄ້ວ

github.com/fluentmigrator/fluentmigrator

ເຄື່ອງມືການເຄື່ອນຍ້າຍທີ່ນິຍົມທີ່ສຸດກັບກອງທັບຂະຫນາດໃຫຍ່ຂອງ fans. ແຈກຢາຍພາຍໃຕ້ໃບອະນຸຍາດ Apache 2.0. ດັ່ງທີ່ໄດ້ກ່າວໄວ້ໃນຄໍາອະທິບາຍ, ມັນເປັນກອບການເຄື່ອນຍ້າຍສໍາລັບ .NET, ຄ້າຍຄືກັບ Ruby on Rails Migrations. ການປ່ຽນແປງລະບົບຖານຂໍ້ມູນແມ່ນໄດ້ອະທິບາຍໄວ້ໃນຫ້ອງຮຽນ C#.

ມີຂໍ້ດີຢູ່ທີ່ນີ້:

• ຮອງຮັບ DBMS ທີ່ຕ້ອງການ
• ຮອງຮັບ .NET Core
• ຊຸມຊົນພັດທະນາຂະຫນາດໃຫຍ່
• ຂໍ້ຂັດແຍ່ງລະຫວ່າງການເຄື່ອນຍ້າຍໄດ້ຖືກແກ້ໄຂຕາມລໍາດັບ - ຄໍາສັ່ງຂອງການປະຕິບັດການເຄື່ອນຍ້າຍໄດ້ຖືກລະບຸໄວ້. ນອກຈາກນັ້ນ, ຖ້າຄວາມຂັດແຍ້ງເກີດຂື້ນກັບຫນ່ວຍງານຫນຶ່ງ, ເມື່ອລວມລະຫັດ, ມັນຖືກແກ້ໄຂໃນລັກສະນະດຽວກັນກັບສ່ວນທີ່ເຫຼືອຂອງລະຫັດ.
• ມີໂປຣໄຟລ໌ທີ່ຖືກປະຕິບັດຫຼັງຈາກການເຄື່ອນຍ້າຍສົບຜົນສໍາເລັດ. ແລະພວກເຂົາສາມາດປະຕິບັດຫນ້າທີ່ການບໍລິການ.ການປັບປຸງຫຼ້າສຸດແມ່ນຫນຶ່ງເດືອນກ່ອນຫນ້ານີ້, ນັ້ນແມ່ນ, ໂຄງການແມ່ນມີຊີວິດຢູ່

ສໍາລັບ minuses, ນີ້ແມ່ນ:

• ບໍ່ມີການຜະລິດອັດຕະໂນມັດຂອງການເຄື່ອນຍ້າຍ
• ບໍ່ມີການເຊື່ອມຕໍ່ກັບຕົວແບບ EF
• ບໍ່ມີພາບຖ່າຍຖານຂໍ້ມູນ

ທາງເລືອກຂອງພວກເຮົາແມ່ນຫຍັງ?

ການໂຕ້ວາທີທີ່ຮ້ອນຮົນໄດ້ໝູນວຽນຮອບສອງຕົວກໍານົດການ - ການຜະລິດການເຄື່ອນຍ້າຍແບບອັດຕະໂນມັດ ແລະການແກ້ໄຂຂໍ້ຂັດແຍ່ງຢ່າງມີສະຕິ. ປັດໃຈອື່ນໆແມ່ນຫນ້າຢ້ານກົວຫນ້ອຍລົງ. ດັ່ງນັ້ນ, ອີງຕາມຜົນໄດ້ຮັບຂອງການສົນທະນາ, ທີມງານໄດ້ຕັດສິນໃຈໃຊ້ Fluent Migrator ໃນໂຄງການໃຫມ່. ເພາະ​ການ​ແກ້​ໄຂ​ຄວາມ​ຂັດ​ແຍ່ງ​ກັນ​ໃນ​ອະນາຄົດ​ຈະ​ນຳ​ມາ​ເຊິ່ງຜົນ​ປະ​ໂຫຍ​ດຫຼາຍ​ກວ່າ​ເກົ່າ.

ການຄົ້ນພົບ

ແນ່ນອນ, ບໍ່ມີເຄື່ອງມືທີ່ສົມບູນແບບ. ດັ່ງ​ນັ້ນ​ພວກ​ເຮົາ​ຕ້ອງ​ຈັດ​ລໍາ​ດັບ "ຄວາມ​ຕ້ອງ​ການ​" ຂອງ​ພວກ​ເຮົາ​ທີ່​ຈະ​ເລືອກ​. ຢ່າງໃດກໍ່ຕາມ, ສໍາລັບທີມງານອື່ນໆແລະວຽກງານອື່ນໆ, ປັດໃຈອື່ນໆອາດຈະເປັນການຕັດສິນໃຈ. ພວກເຮົາຫວັງວ່າບົດຄວາມນີ້ຈະຊ່ວຍໃຫ້ທ່ານເລືອກ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com