مقایسه و انتخاب سیستم های انتقال داده

مقایسه و انتخاب سیستم های انتقال داده

مدل داده در طول فرآیند توسعه تمایل به تغییر دارد و در برخی مواقع دیگر با پایگاه داده مطابقت ندارد. البته می توان پایگاه داده را حذف کرد و سپس 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. کار با ORM در ابتدا قرار بود از EF Core استفاده شود، اما در مرحله طراحی آماده بودیم ORM های دیگر را در نظر بگیریم.
3. تولید خودکار مهاجرت ها با در نظر گرفتن توسعه Code First، می‌خواهم از مهاجرت‌های «دست‌نویس» اجتناب کنم
4. تضاد نسخه در یک محیط توسعه توزیع شده، هنگام ادغام، EF Core ممکن است دچار درگیری شود. این به یک مشکل مهم تبدیل می شود زیرا بخش های مختلف برنامه توسط توسعه دهندگان مختلف ایجاد می شود، بنابراین شما باید زمان زیادی را برای هر یک از آنها صرف کنید.
5. اسناد و پشتیبانی پیشرفته در اینجا، به نظر ما، نیازی به توضیح نیست
6. رایگان. این معیار مشروط است، زیرا سیستم ها بسیار گران یا گران نیستند، اما از نظر راحتی ایده آل هستند، ما نیز آماده بودیم که در نظر بگیریم

در نتیجه کمی تحقیق، گزینه های زیر پیدا شد و برای بررسی مطلوب یافت شد:

1. EF Core Migrations
2. DBup
3. RoundhouseE
4. ThinkingHome.Migrator
5. مهاجر روان

و حالا کمی جزئیات بیشتر

EntityFramework Core Migrations

طبیعتا این اولین و اصلی ترین گزینه برای انتخاب بود. یک ساز بومی که بدون هیچ گونه دستکاری با تنبور کار می کند. حجم زیادی از اسناد، رسمی و نه چندان، سادگی و غیره. با این حال، شکایات ارائه شده در مورد EF کلاسیک برای EF Core نیز کاملاً مرتبط است.

بنابراین، مزایای EF Core برجسته می شود:

• پشتیبانی مایکروسافت، اسناد، از جمله به زبان روسی، جامعه بزرگ
• تولید خودکار مهاجرت ها بر اساس CodeFirst
• در مقایسه با EF 6، EF Core دیگر یک عکس فوری از پایگاه داده ذخیره نمی کند. هنگام کار با EF Core در Code First، دیگر نیازی به استقرار پایگاه داده نیست
• از آنجایی که ما از Code First می رقصیم، می توان یک انتقال به همه ارائه دهندگان دسترسی داده مورد نیاز انجام داد
• در مورد ارائه دهندگان، PostgreSQL پشتیبانی می شود، Oracle پشتیبانی می شود و غیره و غیره، و حتی MS SQL Server 

و همچنین معایب:

• حل تعارض در همان سطح باقی ماند. لازم است که مهاجرت ها ترتیب داده شود و عکس های فوری پایگاه داده به روز شود
• وابستگی به مدل هایی که مهاجرت ها بر اساس آن ها ایجاد می شوند

DbUp

dbup.github.io

DbUp یک کتابخانه دات نت است که توسط NuGet نصب شده و به ایجاد تغییرات در SQL Server کمک می کند. این اسکریپت تغییر قبلاً اجرا شده را پیگیری می کند و مواردی را که برای به روز رسانی پایگاه داده ضروری هستند اجرا می کند. این کتابخانه از پروژه ای برای یک موتور وبلاگ نویسی منبع باز در ASP.NET شکل گرفت و تحت مجوز MIT وجود دارد و کد در GitHub است. مهاجرت ها با استفاده از T-SQL توصیف می شوند.

چه مزایایی دارد:

• پشتیبانی از تعداد زیادی DBMS (MS SQL Server، PstgreSQL، MySQL)
• از آنجایی که اسکریپت ها در T-SQL نوشته شده اند، بسیار ساده به نظر می رسند
• تضادها نیز با استفاده از SQL حل می شوند

و معایب:

• با همه انواع DBMS های پشتیبانی شده، اوراکل یکی از آنها نیست
• با ORM تعامل ندارد
• نوشتن اسکریپت های T-SQL با دست آن چیزی نیست که ما دنبال آن بودیم
• مستندات و جامعه بسیار زیاد است، اگرچه از نظر نوشتن اسکریپت های SQL ممکن است لازم نباشد.

RoundhouseE

github.com/chucknorris/roundhouse

این ابزار مدیریت مهاجرت، که تحت مجوز 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 است - اما این یک سال پیش است)
• بدون تولید خودکار مهاجرت

به طور کلی، این پروژه امیدوارکننده به نظر می رسد، به خصوص اگر قرار باشد توسعه یابد، اما ما باید اینجا و اکنون تصمیم می گرفتیم.

مهاجر روان

github.com/fluentmigrator/fluentmigrator

محبوب ترین ابزار مهاجرت با ارتش زیادی از طرفداران. تحت مجوز آپاچی 2.0 توزیع شده است. همانطور که در توضیحات گفته شد، این یک فریمورک مهاجرت برای دات نت است، مشابه Ruby on Rails Migrations. تغییرات طرحواره پایگاه داده در کلاس های C# توضیح داده شده است.

در اینجا مزایایی وجود دارد:

• پشتیبانی از DBMS مورد نیاز
• پشتیبانی از NET Core
• جامعه توسعه یافته بزرگ
• تضاد بین مهاجرت ها به ترتیب حل می شود - ترتیب اجرای مهاجرت ها مشخص شده است. علاوه بر این، اگر درگیری در اطراف یک موجودیت ایجاد شود، هنگام ادغام کد، به همان روشی حل می شود که در بقیه کدها وجود دارد.
• پروفایل هایی وجود دارند که پس از یک مهاجرت موفق اجرا می شوند. و می توانند توابع سرویس را حمل کنند آخرین آپدیت یک ماه پیش بود یعنی پروژه زنده است

در مورد معایب، در اینجا آنها هستند:

• بدون تولید خودکار مهاجرت
• بدون ارتباط با مدل های EF
• هیچ عکس فوری از پایگاه داده وجود ندارد

انتخاب ما چه بود؟

بحث های داغ حول دو پارامتر می چرخید - ایجاد خودکار مهاجرت ها و حل معقول درگیری ها. عوامل دیگر بسیار کمتر ترسناک بودند. در نتیجه، بر اساس نتایج بحث، تیم تصمیم گرفت از Fluent Migrator در پروژه جدید استفاده کند. زیرا حل تعارضات در آینده مزایای بسیار بیشتری به همراه خواهد داشت.

یافته ها

البته هیچ ابزار کاملی وجود ندارد. بنابراین ما مجبور شدیم «خواسته‌های» خود را برای انتخاب اولویت بندی کنیم. با این حال، برای سایر تیم ها و سایر وظایف، عوامل دیگری ممکن است تعیین کننده باشند. امیدواریم این مقاله به شما در انتخاب کمک کند.

منبع: www.habr.com