مقارنة واختيار نظم ترحيل البيانات

مقارنة واختيار نظم ترحيل البيانات

يحتوي نموذج البيانات في عملية التطوير على خاصية التغيير ، وفي مرحلة ما يتوقف عن التطابق مع قاعدة البيانات. بالطبع ، يمكن حذف قاعدة البيانات ، ثم يقوم ORM بإنشاء نسخة جديدة تتوافق مع النموذج ، ولكن مثل هذا الإجراء سيؤدي إلى فقدان البيانات الموجودة. وبالتالي ، تتمثل وظيفة نظام الترحيل في التأكد من أنه نتيجة لتغيير النظام ، قم بمزامنته مع نموذج البيانات في التطبيق دون فقد البيانات الموجودة.

في هذه المقالة ، نود أن نأخذ في الاعتبار الأدوات المختلفة لإدارة عمليات ترحيل قاعدة البيانات. نأمل أن تكون هذه المراجعة مفيدة للمطورين الذين يواجهون هذا الاختيار.

مهمة

تعمل شركتنا حاليًا على تطوير الجيل التالي من المنتج - Docs Security Suite (DSS). تتم كتابة جزء الخادم على .Net Core ، ويستخدم Entity Framework Core على التوالي كنظام إدارة قواعد البيانات. عند تصميم التطبيق ، نستخدم نهج Code First.

يتم إنشاء نموذج المجال للتطبيق من قبل العديد من المطورين في نفس الوقت - كل واحد مسؤول عن الجزء المنطقي الخاص به من النظام.

في الجيل السابق من DSS ، تم استخدام Entourage Framework Migrations (EF 6) الكلاسيكية كنظام لإدارة الترحيل. ومع ذلك ، تراكمت بعض المطالبات ضدها ، وأهمها أن EF تفتقر إلى نهج عاقل لحل تعارضات الإصدار. لا تزال هذه الحقيقة تزعجنا عند إصلاح الخلل في إطار الدعم ، لذلك تقرر التفكير في خيارات بديلة.

نتيجة للمناقشة ، تم تشكيل المتطلبات التالية لنظام إدارة الترحيل:

1. دعم مختلف نظم إدارة قواعد البيانات. إلزامي MS SQL Server و PostgreSQL و Oracle ، لكن يُحتمل أن تستخدم أخرى
2. العمل مع ORM. في البداية ، كان من المفترض استخدام EF Core ، ولكن في مرحلة التصميم ، كانت مكاتب ORM الأخرى جاهزة للنظر فيها
3. التوليد التلقائي للهجرات. بالنظر إلى تطوير الكود أولاً ، أود تجنب الحاجة إلى "الطلاء باستخدام الأقلام"
4. تعارضات الإصدار. في بيئة تطوير موزعة مع الدمج ، يمكن أن تتعطل EF Core في الصراعات. تصبح هذه مشكلة كبيرة ، نظرًا لأن أجزاء مختلفة من التطبيق يتم إنشاؤها بواسطة مطورين مختلفين ، لذلك يتعين عليك قضاء الكثير من الوقت لكل منهم
5. الوثائق المتقدمة والدعم. هنا ، يبدو لنا ، لا حاجة إلى شرح
6. مجانا. المعيار الشرطي ، نظرًا لأن الأنظمة ليست باهظة الثمن أو باهظة الثمن ، ولكنها مثالية في الراحة ، فقد كنا أيضًا على استعداد للنظر

نتيجة لدراسة صغيرة ، تم العثور على الخيارات التالية واعتبارها مرغوبة للنظر فيها:

1. هجرة الأساسية ef
2. DBup
3. القاطرات
4. ThinkingHome.Migrator
5. المهاجر بطلاقة

والآن أكثر من ذلك بقليل

الهجرات الأساسية EntityFramework

بطبيعة الحال ، كان هذا الخيار الأول والرئيسي للاختيار. أداة أصلية تعمل خارج الصندوق دون أي رقصة مع الدف. كمية كبيرة من الوثائق ، الرسمية وغير البساطة ، إلخ. ومع ذلك ، فإن المطالبات المقدمة إلى EF الكلاسيكية هي ذات صلة وثيقة بـ EF Core.

وبالتالي ، يتم تسليط الضوء على مزايا EF Core:

• دعم Microsoft والوثائق ، بما في ذلك باللغة الروسية ، مجتمع ضخم
• الترحيل التلقائي المستندة إلى CodeFirst
• مقارنةً بـ EF 6 ، لم تعد لقطة قاعدة البيانات مخزنة في EF Core. عند العمل مع EF Core في Code First ، لم تعد مضطرًا إلى نشر قاعدة بيانات
• نظرًا لأننا نرقص من Code First - فمن الممكن إجراء عملية ترحيل واحدة لجميع موفري الوصول إلى البيانات المطلوبين
• فيما يتعلق بموفري الخدمات - PostgreSQL ، أوراكل ، وما إلى ذلك ، وما إلى ذلك ، وحتى ، - يتم دعم MS SQL Server في وقت واحد

وكذلك سلبيات:

• بقي حل النزاع على نفس المستوى. من الضروري إنشاء سلسلة من عمليات الترحيل وتحديث صور قاعدة البيانات
• الاعتماد على النماذج التي تم إنشاؤها على أساسها الهجرات

DbUp


dbup.imtqy.com

DbUp هي مكتبة .NET مثبتة بواسطة NuGet ويساعد على لفة التغييرات إلى SQL Server. يتتبع تتبع البرامج النصية للتغيير التي تم تنفيذها بالفعل ، ويقوم بتشغيل تلك المطلوبة لتحديث قاعدة البيانات. نشأت المكتبة من مشروع محرك مدونة مفتوح المصدر لـ ASP.NET وهي موجودة بموجب ترخيص MIT ، والرمز موجود على GitHub. يتم وصف عمليات الترحيل باستخدام T-SQL.

ما هي المزايا:

• دعم لعدد كبير من قواعد البيانات (MS SQL Server ، PstgreSQL ، MySQL)
• منذ كتابة البرامج النصية في T-SQL ، فإنها تبدو بسيطة جدا
• يتم حل النزاعات أيضًا باستخدام SQL

سلبيات:

• مع كل مجموعة متنوعة من قواعد البيانات المدعومة ، فإن Oracle ليست من بينها.
• لا يتفاعل مع ORM
• كتابة البرامج النصية T-SQL مع الأقلام ليس هو ما كنا نهدف إليه
• التوثيق والمجتمع على هذا النحو ، على الرغم من أنه قد لا تكون هناك حاجة في سياق كتابة البرامج النصية SQL.

القاطرات


github.com/chucknorris/roundhouse

تعمل أداة إدارة الترحيل هذه ، الموزعة بموجب ترخيص Apache 2.0 ، مثل الأداة السابقة ، على محرك الترحيل T-SQL. على ما يبدو ، ركز المطورون على حل المشكلات الفنية المتعلقة بدعم قواعد البيانات ، بدلاً من إنشاء عملية تطوير مريحة.

الايجابيات:

• يدعم نظم إدارة قواعد البيانات اللازمة (بما في ذلك أوراكل)

سلبيات:

• لا يتم دعم Oracle (وكذلك Access غير ذي صلة بالنسبة لنا) على .NET Core ، فقط على .NET Full Framework
• لا يعمل مع ORM
• هناك وثائق أقل من الأداة السابقة
• مرة أخرى - تتم كتابة الهجرات في البرامج النصية

ThinkingHome.Migrator



أداة لترحيل الإصدار لمخطط قاعدة البيانات لنظام .NET Core الأساسي ، الموزع بموجب ترخيص MIT. كتب المطور نفسه عن أحدث إصدار منذ عام تقريبًا .

الايجابيات:

• شحذ تحت. NET الأساسية
• نفذت المتفرعة تسلسل الهجرات
• تم تنفيذ تسجيل الترحيل

سلبيات:

• آخر تحديث - قبل عام. على ما يبدو ، المشروع غير مدعوم.
• غير مدعوم من أوراكل (تنص المقالة على أن هذا يرجع إلى عدم وجود تطبيق مستقر لبرنامج .NET Core - لكن هذا منذ عام مضى)
• مفقود توليد تلقائي للهجرات

بشكل عام ، يبدو المشروع واعداً ، خاصة إذا كان سيتطور ، لكننا كنا بحاجة لاتخاذ قرار هنا والآن.

المهاجر بطلاقة


github.com/fluentmigrator/fluentmigrator

أداة الهجرة الأكثر شعبية مع جيش كبير من المشجعين. موزعة تحت رخصة أباتشي 2.0. كما هو مذكور في الوصف ، فهو عبارة عن منصة ترحيل لـ .NET ، مماثلة لـ Ruby on Rails Migrations. التغييرات في مخطط قاعدة البيانات موصوفة في الفئات في C #.

هناك إيجابيات:

• دعم اللازمة ل DBMS
• الدعم الصافي
• مجتمع متطور كبير
• يتم حل تعارضات الترحيل بالتتابع - يشار إلى ترتيب التنفيذ لعمليات الترحيل. بالإضافة إلى ذلك ، إذا كان هناك تعارض حول كيان واحد ، عند دمج الكود ، فسيتم تنفيذ الحل بنفس الطريقة المتبعة في باقي الكود
• هناك ملفات تعريف يتم تشغيلها بعد ترحيل ناجح. ويمكن أن تحمل وظائف الخدمة. وكان آخر تحديث قبل شهر ، أي أن المشروع يعيش

بالنسبة للسلبيات ، هنا:

• مفقود توليد تلقائي للهجرات
• لا يوجد اتصال مع نماذج EF
• لا توجد لقطات قاعدة بيانات

ماذا كان اختيارنا؟

كان النقاش الأكثر سخونة يدور حول معلمتين - التوليد التلقائي للهجرات وحل النزاعات المعقول. عوامل أخرى خائفة أقل بكثير. نتيجة لذلك ، ونتيجة للمناقشة ، قرر الفريق استخدام Fluent Migrator في المشروع الجديد. لحل الصراعات في المستقبل سوف يجلب الكثير من المزايا.

النتائج

بالطبع ، لا توجد أدوات مثالية. لذلك كان علينا أن نعطي الأولوية لقائمة "مفضلة" لدينا للاختيار. ومع ذلك ، قد تكون هناك عوامل أخرى حاسمة للفرق الأخرى والمهام الأخرى. نأمل أن تساعدك هذه المقالة على اتخاذ قرار.