Տվյալների միգրացիոն համակարգերի համեմատություն և ընտրություն
Տվյալների մոդելը հակված է փոփոխության զարգացման գործընթացում, և ինչ-որ պահի այն այլևս չի համապատասխանում տվյալների բազային: Իհարկե, տվյալների բազան կարող է ջնջվել, իսկ հետո ORM-ը կստեղծի նոր տարբերակ, որը կհամապատասխանի մոդելին, սակայն այս ընթացակարգը կհանգեցնի առկա տվյալների կորստի: Այսպիսով, միգրացիոն համակարգի գործառույթն է ապահովել, որ սխեմայի փոփոխության արդյունքում այն համաժամանակացվի հավելվածում առկա տվյալների մոդելի հետ՝ չկորցնելով առկա տվյալները:
Այս հոդվածում մենք կցանկանայինք դիտարկել տվյալների բազայի միգրացիան կառավարելու տարբեր գործիքներ: Հուսով ենք, որ այս վերանայումը օգտակար կլինի նմանատիպ ընտրության առջև կանգնած ծրագրավորողների համար:
Առաջադրանք
Մեր ընկերությունը ներկայումս ակտիվորեն զարգացնում է արտադրանքի հաջորդ սերունդը՝ Docs Security Suite (DSS): Սերվերի մասը գրված է .Net Core-ով, իսկ Entity Framework Core-ն օգտագործվում է որպես DBMS: Հավելվածը նախագծելիս մենք օգտագործում ենք Code First մոտեցումը:
Հավելվածի տիրույթի մոդելը ստեղծվում է միաժամանակ մի քանի մշակողների կողմից. յուրաքանչյուրը պատասխանատու է համակարգի իր տրամաբանական մասի համար:
DSS-ի նախորդ սերունդը որպես միգրացիայի կառավարման համակարգ օգտագործում էր դասական Entity Framework Migrations (EF 6): Այնուամենայնիվ, դրա դեմ որոշ բողոքներ են կուտակվել, որոնցից հիմնականն այն է, որ EF-ն չունի խելամիտ մոտեցում տարբերակների կոնֆլիկտները լուծելու համար: Այս փաստը դեռևս վրդովեցնում է մեզ, երբ շտկում ենք սխալները որպես աջակցության մաս, ուստի մենք որոշեցինք դիտարկել այլընտրանքային տարբերակներ:
Քննարկման արդյունքում ձևավորվել են միգրացիայի կառավարման համակարգի հետևյալ պահանջները.
- Աջակցություն տարբեր DBMS-ների համար: Պահանջվում են MS SQL Server, PostgreSQL, Oracle, բայց հնարավոր է, որ հնարավոր է օգտագործել ուրիշներ
- Աշխատում է ORM-ի հետ: Սկզբում նախատեսվում էր օգտագործել EF Core-ը, սակայն նախագծման փուլում մենք պատրաստ էինք դիտարկել այլ ORM-ներ:
- Միգրացիաների ավտոմատ գեներացիա: Հաշվի առնելով Code First-ի զարգացումը, ես կցանկանայի խուսափել «ձեռագիր» միգրացիաների անհրաժեշտությունից
- Տարբերակների հակասություններ. Բաշխված զարգացման միջավայրում, երբ միաձուլվում է, EF Core-ը կարող է տուժել կոնֆլիկտներից: Սա էական խնդիր է դառնում, քանի որ հավելվածի տարբեր մասեր ստեղծվում են տարբեր ծրագրավորողների կողմից, այնպես որ դուք պետք է շատ ժամանակ ծախսեք յուրաքանչյուրի վրա:
- Ընդլայնված փաստաթղթեր և աջակցություն: Այստեղ, մեզ թվում է, բացատրություն պետք չէ
- Անվճար. Չափանիշը պայմանական է, քանի որ համակարգերը շատ թանկ կամ թանկ չեն, բայց հարմարության մեջ իդեալական են, մենք նույնպես պատրաստ էինք դիտարկել.
Փոքրիկ հետազոտության արդյունքում գտնվել և դիտարկման համար ցանկալի են եղել հետևյալ տարբերակները.
- EF հիմնական միգրացիաներ
- DBup
- RoundhouseE
- ThinkingHome.Migrator
- Սահուն միգրատոր
Իսկ հիմա մի փոքր ավելի մանրամասն
Բնականաբար, սա ընտրության առաջին և հիմնական տարբերակն էր։ Հարազատ գործիք, որն աշխատում է առանց դափի հետ շփվելու: Մեծ քանակությամբ փաստաթղթեր, պաշտոնական և ոչ այնքան, պարզություն և այլն: Այնուամենայնիվ, դասական EF-ի վերաբերյալ արված բողոքները բավականին տեղին են նաև EF Core-ի համար:
Այսպիսով, EF Core-ի առավելությունները կարևորվում են.
- Microsoft-ի աջակցություն, փաստաթղթեր, ներառյալ ռուսերեն, հսկայական համայնք
- Միգրացիաների ավտոմատ գեներացում՝ հիմնված CodeFirst-ի վրա
- EF 6-ի համեմատ, EF Core-ն այլևս չի պահում տվյալների բազայի պատկերը: Code First-ում EF Core-ի հետ աշխատելիս այլևս անհրաժեշտ չէ տվյալների բազա տեղակայել
- Քանի որ մենք պարում ենք Code First-ից, հնարավոր է մեկ տեղափոխում կատարել տվյալների հասանելիության բոլոր պահանջվող մատակարարներին
- Ինչ վերաբերում է մատակարարներին, PostgreSQL-ն աջակցվում է, Oracle-ն աջակցվում է և այլն, և այլն, և նույնիսկ MS SQL Server
Եվ նաև թերությունները.
- Հակամարտությունների լուծումը մնաց նույն մակարդակի վրա. Անհրաժեշտ է հաջորդականացնել միգրացիաները և թարմացնել տվյալների բազայի նկարները
- Կախվածություն մոդելներից, որոնց վրա ստեղծվում են միգրացիաները
DbUp
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 սցենարներ գրելու առումով դրանք կարող են անհրաժեշտ չլինել:
RoundhouseE
Միգրացիայի կառավարման այս գործիքը, որը բաշխված է Apache 2.0 լիցենզիայի ներքո, ինչպես նախորդը, աշխատում է T-SQL միգրացիոն շարժիչով: Ըստ երևույթին, մշակողները առաջնահերթություն են տվել DBMS-ի աջակցության հետ կապված տեխնիկական խնդիրների լուծմանը, այլ ոչ թե ստեղծելու հարմարավետ զարգացման գործընթաց:
Կոալիցիայում:
- Աջակցում է անհրաժեշտ DBMS-ին (ներառյալ Oracle-ը)
Դեմ:
- Oracle-ը (ինչպես նաև Access-ը, որը մեզ համար անտեղի է) չի աջակցվում .NET Core-ում, միայն .NET Full Framework-ում:
- Չի աշխատում ORM-ի հետ
- Նույնիսկ ավելի քիչ փաստաթղթեր կան, քան նախորդ գործիքը
- Կրկին – միգրացիաները գրվում են սցենարներով
ThinkingHome.Migrator
Տվյալների տվյալների բազայի սխեմայի տարբերակված միգրացիայի գործիք .NET Core հարթակ, որը բաշխված է MIT լիցենզիայի ներքո: .
Կոալիցիայում:
- Նախատեսված է .NET Core-ի համար
- Իրականացրել է միգրացիաների ճյուղավորվող հաջորդականություն
- Իրականացվել է միգրացիայի գրանցում
Դեմ:
- Վերջին անգամ թարմացվել է մեկ տարի առաջ: Ըստ երևույթին, նախագիծը չի աջակցվում
- Չի աջակցվում Oracle-ի կողմից (հոդվածում ասվում է, որ դա պայմանավորված է .NET Core-ի կայուն ներդրման բացակայության պատճառով, բայց սա մեկ տարի առաջ է)
- Միգրացիաների ավտոմատ սերունդ չկա
Ընդհանուր առմամբ, նախագիծը խոստումնալից է թվում, հատկապես, եթե այն զարգանա, բայց մենք պետք է որոշում կայացնեինք այստեղ և հիմա:
Սահուն միգրատոր
Ամենահայտնի միգրացիոն գործիքը երկրպագուների մեծ բանակով: Բաշխված է Apache 2.0 լիցենզիայի ներքո: Ինչպես նշված է նկարագրության մեջ, դա .NET-ի միգրացիոն շրջանակ է, որը նման է Ruby on Rails Migrations-ին: Տվյալների բազայի սխեմայի փոփոխությունները նկարագրված են C# դասերում:
Այստեղ կան առավելություններ.
- Աջակցություն պահանջվող DBMS-ին
- .NET Core աջակցություն
- Խոշոր զարգացած համայնք
- Միգրացիաների միջև կոնֆլիկտները լուծվում են հաջորդաբար. նշվում է միգրացիաների կատարման կարգը: Բացի այդ, եթե կոնֆլիկտ է ծագում մեկ սուբյեկտի շուրջ, կոդը միաձուլելիս այն լուծվում է այնպես, ինչպես մնացած կոդի մեջ։
- Կան պրոֆիլներ, որոնք կատարվում են հաջող միգրացիայից հետո: Եվ դրանք կարող են կրել սպասարկման գործառույթներ:Վերջին թարմացումը եղել է մեկ ամիս առաջ, այսինքն՝ նախագիծը կենդանի է
Ինչ վերաբերում է մինուսներին, ապա դրանք հետևյալն են.
- Միգրացիաների ավտոմատ սերունդ չկա
- Ոչ մի կապ EF մոդելների հետ
- Տվյալների բազայի նկարներ չկան
Ո՞րն էր մեր ընտրությունը:
Թեժ բանավեճերը ծավալվեցին երկու պարամետրի շուրջ՝ միգրացիաների ավտոմատ առաջացում և հակամարտությունների ողջամիտ լուծում։ Մյուս գործոնները շատ ավելի քիչ վախեցնող էին: Արդյունքում, քննարկման արդյունքների հիման վրա թիմը որոշեց օգտագործել Fluent Migrator-ը նոր նախագծում։ Քանի որ ապագայում հակամարտությունների լուծումը շատ ավելի մեծ օգուտներ կբերի:
Արդյունքները
Իհարկե, չկան կատարյալ գործիքներ: Այսպիսով, մենք պետք է առաջնահերթություն դնեինք ընտրություն կատարելու մեր «ցանկություններին»: Այնուամենայնիվ, այլ թիմերի և այլ առաջադրանքների համար այլ գործոններ կարող են որոշիչ լինել: Հուսով ենք, որ այս հոդվածը կօգնի ձեզ ընտրություն կատարել:
Source: www.habr.com