DevOps لقواعد البيانات · ترحيل المخطط

ترحيل مخطط قاعدة البيانات: كيف تغيّرون مخططًا يعمل بأمان، وكيف تعودون إن لزم

ترحيل مخطط قاعدة البيانات تغيير مضبوط في بنية قاعدة البيانات: عمود جديد، أو فهرس معدَّل، أو عرض (view) أُعيدت كتابته. وهو غير نقل البيانات إلى منصة جديدة. يشرح هذا الدليل النهجين المتّبعين، وكيف تُكتب سكربتات الترحيل، وطرق العودة حين يفشل تغيير، وأين تناسب أداة Flyway من Redgate الفرق في السعودية.

نُشر في 10 نوفمبر 2026 8 دقائق قراءة

راجعوا طريقة ترحيل المخطط لديكم طرق التراجع

الملخص

نظرة سريعة

خلاصة الصفحة في جدول واحد، قبل التفاصيل.

ما هو: تغيير مرقَّم ومراجَع في الجداول أو الفهارس أو العروض أو الإجراءات المخزنة أو الصلاحيات
ما ليس هو: نقل البيانات بين قواعد البيانات أو المنصات؛ فذلك ترحيل بيانات
نهجان: قائم على الترحيلات (سكربتات مرتّبة) أو قائم على الحالة (نموذج للمخطط المطلوب)
أكثر المخاطر شيوعًا: انحراف البيئات عن بعضها، وتغييرات تقفل الجداول، وغياب طريق عودة مجرَّب
الأداة التي تنفّذها إنتركي: Flyway من Redgate: ترحيلات مرقّمة ومتكررة وتراجع وخط أساس
المنصات: SQL Server وOracle وMySQL وPostgreSQL وغيرها، بحسب قائمة Redgate

المشكلة بكلمات بسيطة

الوضع المعتاد: تغييرات المخطط تُكتب يدويًا، ويطبّقها شخص واحد ليلًا، ولا أحد متأكد أن كل بيئة تلقّت التغييرات نفسها.
ما الذي يحدث: تغيير نجح في الاختبار يقفل جدولًا كبيرًا في الإنتاج، أو يتوقف في منتصفه، فلا يبقى للعودة إلا الاستعادة من نسخة احتياطية.
ما الذي يغيّره الانضباط في الترحيل: كل تغيير سكربت مرقَّم، يُراجَع، وتطبّقه أداة مرة واحدة بالترتيب، ويُسجَّل في قاعدة البيانات نفسها.
القرار المطلوب من الإدارة: أن يكون طريق العودة جزءًا من كل تغيير، يُخطَّط له قبل النشر لا بعد الفشل.

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

ترحيل المخطط يغيّر شكل قاعدة البيانات وتبقى بياناتها في مكانها: إضافة عمود، أو تقسيم جدول، أو تعديل قيد. ولكل تغيير سكربت برقم إصدار، وتطبّق الأداة السكربتات المعلّقة بالترتيب وتسجّل كلًّا منها، فتعرف كل قاعدة بيانات إصدارها.

أما ترحيل البيانات فعمل آخر: نقل السجلات من قاعدة بيانات أو منصة إلى أخرى، وكثيرًا ما تعمل الاثنتان معًا مدة. وهذا العمل، بما فيه من توقف وتحقق، مشروح في صفحة ترحيل البيانات وقواعد البيانات، وتنفّذه إنتركي بمنصتها iblync للترحيل والنسخ المتزامن. ويلتقي العملان في نقطة واحدة: أن تعمل قاعدة الهدف الجديدة تحت ضبط ترحيل المخطط من يومها الأول.

النهج القائم على الترحيلات والنهج القائم على الحالة

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

مقارنة بين النهج القائم على الترحيلات والنهج القائم على الحالة في تغيير مخطط قاعدة البيانات
	القائم على الترحيلات	القائم على الحالة
ما تكتبونه	كل تغيير سكربتًا مرقَّمًا	التعريف المطلوب لكل كائن
من أين يأتي سكربت النشر	هو السكربت المراجَع نفسه	تولّده أداة مقارنة من الفرق بين الحالتين
نقطة القوة	ما يُنفَّذ في الإنتاج هو بالضبط ما روجع، وبالترتيب نفسه	تعريف الكائن كاملًا في ملف واحد، فيسهل تتبّع تاريخه
نقطة الضعف	تاريخ الكائن الواحد موزّع على سكربتات كثيرة	إعادة التسمية أو تقسيم العمود قد تُفهم حذفًا وإنشاءً، فيلزم فحص السكربت المولَّد
يناسب حين	تمسّ التغييرات البيانات أو أسماء الكائنات أو الجداول الكبيرة	يعدّل أشخاص كثيرون الإجراءات المخزنة والعروض
الشائع عمليًا	سكربتات مرقّمة للجداول والبيانات	سكربتات متكررة أو نموذج مخطط لكائنات الكود

أغلب الفرق تجمع بين النهجين: سكربتات ترحيل للجداول والبيانات، ونظرة قائمة على الحالة لكائنات الكود. وتذكر وثائق Redgate أن Flyway تعمل بالترحيلات، وأنها تستطيع أيضًا حفظ نموذج للمخطط في منصات منها MySQL وPostgreSQL وSQL Server. وتجدون أساسيات حفظ المخطط في مستودع في صفحة التحكم في إصدارات قواعد البيانات.

ترحيلات Flyway: المرقّمة والمتكررة والتراجع وخط الأساس

تتعرّف Flyway على السكربتات من أسماء ملفاتها، والبادئة تحدد نوع كل ترحيل.

أنواع ترحيلات Flyway وأسماء ملفاتها ومتى يُنفَّذ كل نوع، كما توثّقها Redgate
النوع	مثال لاسم الملف	متى يُنفَّذ	يُستخدم لـ
مرقَّم (Versioned)	`V001.002__NewTwitterColumn.sql`	مرة واحدة في كل قاعدة بيانات، بترتيب الإصدارات	الجداول والأعمدة والقيود وتصحيح البيانات
متكرر (Repeatable)	`R__SetDefaults.sql`	بعد الترحيلات المرقّمة المعلّقة، كلما تغيّر المجموع الاختباري (checksum)	العروض والإجراءات المخزنة والدوال والحزم والبيانات المرجعية
تراجع (Undo)	`U001.002__UndoNewTwitterColumn.sql`	عند تشغيل أمر التراجع فقط	عكس الترحيل المرقَّم الذي يحمل الإصدار نفسه
خط أساس (Baseline)	`B5__my_database.sql`	في البيئات الجديدة فقط	بناء قاعدة بيانات جديدة دون إعادة تشغيل التاريخ القديم

أمثلة الأسماء من وثائق Redgate عن الترحيلات المرقّمة والمتكررة والتراجع وخط الأساس، قُرئت في 10 نوفمبر 2026. وتحفظ Flyway المجموع الاختباري لكل سكربت في الجدول flyway_schema_history، فإذا عُدّل سكربت مرقَّم بعد تطبيقه اكتُشف ذلك. وتضع Redgate ترحيلات التراجع ضمن إصداراتها المدفوعة لا ضمن Community، وتقارن صفحة إصدارات Flyway بين الإصدارات.

كتابة سكربتات ترحيل قاعدة البيانات لتصمد في الإنتاج

الأداة تطبّق كل ما يُعطى لها. وهذه العادات هي التي تجعل التغيير آمنًا:

غرض واحد لكل سكربت. التغيير الصغير أسهل في المراجعة والاختبار والعكس.
لا تعدّلوا ترحيلًا طُبّق. نصيحة Redgate أن تمضوا إلى الأمام بسكربت جديد متى وصل الترحيل إلى بيئة دائمة.
التوسيع ثم التقليص. أضيفوا العمود أو الجدول الجديد، وانقلوا القراءة والكتابة إليه، ثم احذفوا القديم في إصدار لاحق، فيبقى كل إصدار من التطبيق عاملًا.
اجعلوا السكربتات المتكررة آمنة عند إعادة التشغيل. استخدموا CREATE OR REPLACE أو ما يقابله في منصتكم.
انقلوا البيانات الكبيرة على دفعات. تحديث واحد على جدول كبير قد يقفله ويملأ سجل المعاملات.
اعرفوا سلوك منصتكم مع أوامر البنية (DDL). بعض المحركات تنفّذ تغييرات البنية داخل معاملة، وبعضها يثبّت كل أمر وحده، فقد يتوقف سكربت فاشل في منتصفه. راجعوا وثائق محرككم.
اكتبوا العكس في الوقت نفسه. وجرّبوه في بيئة أدنى قبل أن يصل التغيير إلى الإنتاج.

انحراف المخطط: حين لا تطابق قاعدة البيانات سكربتاتها

من أين يأتي الانحراف، وماذا تفعلون به

الانحراف هو أي فرق بين ما تقوله الترحيلات وما تحمله قاعدة البيانات فعلًا. ويظهر حين يصلح أحدهم الإنتاج يدويًا، أو حين تُبنى بيئة اختبار من نسخة احتياطية قديمة. وهو يُفشل الترحيلات بطرق غير متوقعة: سكربت يضيف عمودًا فيفشل لأن العمود موجود أصلًا. ومن أسبابه الشائعة أيضًا فهرس أُضيف على عجل لحل مشكلة أداء، أو صلاحية مُنحت مباشرة على الخادم، أو إجراء مخزن عُدّل لإصلاح عاجل ثم نُسي. كل واحد منها صغير، لكنه يجعل البيئات تختلف دون أن يعلم أحد.

افحصوا الانحراف قبل كل نشر، لا بعد العطل. وتذكر Redgate اكتشاف الانحراف وتقارير التغيير ضمن Flyway Enterprise، وتبيّن صفحة التكامل والنشر المستمر لقواعد البيانات موضع هذه التقارير في خط التسليم. ويبقى القرار لشخص يحدد هل كان الفرق مقصودًا.

سكربتات التراجع وطرق العودة الأخرى: جدول قرار

سكربت التراجع طريق واحد للعودة، لا الطريق الوحيد. اختاروا لكل تغيير قبل نشره.

طرق التعافي من ترحيل مخطط فاشل، ومتى تنجح كل طريقة وحدودها
طريق العودة	ينجح حين	حدوده
سكربت تراجع	كان التغيير في البنية واكتمل كله	لا يعيد البيانات المحذوفة أو المستبدلة، ويفترض أن الترحيل نجح بكامله
المضي إلى الأمام بتصحيح	الخلل صغير ويمكن مراجعة سكربت تصحيح بسرعة	يحتاج إلى خط تسليم سريع وموثوق لتطبيق التصحيح
تغيير متوافق مع الإصدار السابق	استُخدم التوسيع ثم التقليص، فبقي إصدار التطبيق القديم عاملًا	يحتاج التغيير إلى إصدارين أو أكثر ليكتمل
الاستعادة من نسخة احتياطية	تضررت البيانات ولا طريق آخر لاستعادتها	تضيع التغييرات التي جاءت بعد النسخة، ويلزم التدرّب عليها مسبقًا
مفتاح ميزة في التطبيق	المخطط سليم والمشكلة في السلوك الجديد	لا يعكس تغيير المخطط نفسه

وتنبّه وثائق Redgate عن التراجع إلى الأمر نفسه: سكربتات التراجع تناسب البنية أكثر من البيانات، وتوصي بإبقاء قاعدة البيانات متوافقة مع كل إصدار مستخدم من التطبيق، مع خطة نسخ احتياطي واستعادة مجرَّبة.

ترحيل المخطط في السعودية: بيانات الاختبار والسجلات والدعم

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

اقرأ المزيد

والثاني أن التدقيق الداخلي يسأل: من غيّر قاعدة البيانات، ومتى، وبموافقة من؟ والترحيلات المرقّمة وجدول السجل وموافقات خط التسليم تجيب عن ذلك نتيجةً طبيعية للتغيير نفسه.

والثالث الدعم. يعمل مهندسو إنتركي من الرياض، بالعربية والإنجليزية، إلى جانب مسؤولي قواعد البيانات لديكم. وتعمل Flyway على خوادمكم وخطوط التسليم لديكم، فتبقى قواعد البيانات وبياناتها حيث هي اليوم، ولا يتغير شيء في إقامة البيانات بتغيّر طريقة التغيير.

أين تناسب Flyway، وأين لا تناسب

Flyway هي أداة ترحيل المخطط التي تنفّذها إنتركي. وتذكر Redgate أن من قواعد البيانات المدعومة Oracle وSQL Server وMySQL وPostgreSQL، مع نطاقات الإصدارات في صفحة قواعد البيانات المدعومة، وأنها تدعم أكثر من 60 منصة إجمالًا. فأداة واحدة ونظام تسمية واحد يغطيان بيئة متعددة المنصات. وتعمل Flyway من سطر الأوامر أو Docker، فتدخل في خط التسليم القائم لديكم، وتشرح صفحة DevOps لقواعد البيانات الممارسة المحيطة بها.

اقرأ المزيد

وأين لا تناسب: لا تنقل Flyway البيانات بين المنصات، فالانتقال إلى محرك جديد يحتاج أيضًا إلى أداة لترحيل البيانات. ولا تحسّن الاستعلامات البطيئة. وتطبّق أي ترحيل يُعطى لها، آمنًا كان أو لا؛ فالعادات المذكورة أعلاه هي التي تجعل التغيير آمنًا. وإن كانت لدى الفريق قاعدة بيانات واحدة وتغييرات قليلة ولا أسئلة من التدقيق، فقد تكفي طريقة أخف، وسنقول ذلك بوضوح.

روابط ذات صلةصفحة قواعد البيانات المدعومة

كيف تساعدكم إنتركي

Flyway من صنع Redgate، وإنتركي تتولى العمل المحيط بها. ونسعّر ترخيص Redgate وفق شروطها إلى جانب عملنا في عرض واحد. وعلى سبيل التقدير، يستغرق أول مخطط أسابيع، أما البيئة كاملة فتتوقف على عدد قواعد البيانات، ومقدار انحرافها، وعدد التغييرات التي ما زالت تحتاج إلى نافذة صيانة.

التقاط خط الأساس.

تسجيل الإنتاج إصدارًا أول، ومقارنة كل بيئة به.
اختيار النهج.

الاتفاق على الكائنات التي تُدار بالترحيلات وتلك التي تُدار بالحالة، وعلى قواعد التسمية.
تجربة على مخطط واحد.

تشغيل Flyway على مخطط كثير التغيير في بيئة أدنى، عبر خط التسليم لديكم.
التدرّب على طريق العودة.

اختيار طريق العودة لكل نوع من التغييرات وتجربته قبل الإنتاج.
التسليم أو التشغيل.

كتابة المعايير وتدريب الفريق، أو تشغيل العملية نيابة عنكم من الرياض.

أسئلة يطرحها المشترون عن ترحيل المخطط

ما الفرق بين ترحيل مخطط قاعدة البيانات وترحيل البيانات؟

ترحيل المخطط يغيّر بنية قاعدة البيانات وتبقى البيانات في مكانها. أما ترحيل البيانات فينقل السجلات من قاعدة بيانات أو منصة إلى أخرى. والانتقال إلى منصة جديدة يحتاج عادة إلى الاثنين: نقل البيانات، ووضع المخطط الجديد تحت ضبط الترحيل من يومه الأول.

هل نعتمد النهج القائم على الترحيلات أم القائم على الحالة في تغييرات المخطط؟

أغلب الفرق تجمع بينهما. السكربتات المرقّمة تناسب الجداول وإعادة التسمية وتغييرات البيانات، لأن ما يُنفَّذ هو ما روجع. والنموذج القائم على الحالة يناسب العروض والإجراءات التي يعدّلها كثيرون. ونتفق معكم على التقسيم بحسب نوع الكائن.

كيف نتراجع عن ترحيل مخطط فشل في الإنتاج؟

اختاروا طريق العودة قبل النشر: سكربت تراجع لتغيير في البنية اكتمل، أو تصحيح إلى الأمام لخلل صغير، أو استعادة من نسخة احتياطية إذا تضررت البيانات. والتغييرات المكتوبة بأسلوب التوسيع ثم التقليص لا تحتاج في الغالب إلى تراجع.

هل تدير أداة واحدة ترحيلات المخطط على Oracle وSQL Server وPostgreSQL معًا؟

نعم. تذكر Redgate أن Flyway تدعم Oracle وSQL Server وMySQL وPostgreSQL، فيغطي نظام تسمية واحد ونمط واحد لجدول السجل بيئة متعددة المنصات. وتختلف الإصدارات المدعومة بحسب المحرك، ونتحقق من إصداراتكم أثناء تحديد النطاق.

كم تكلّف أدوات ترحيل المخطط جهة في السعودية، وكم تستغرق؟

للتكلفة جزءان: ترخيص Redgate وفق شروطها، وعمل إنتركي بنطاق يُحدَّد لكل بيئة. وعلى سبيل التقدير، يستغرق أول مخطط أسابيع، والبيئة كاملة تتوقف على عدد قواعد البيانات، ومقدار انحرافها، والإصدار الذي تحتاجونه.

هل تخرج بياناتنا من المملكة إذا أعدّت إنتركي ترحيلات المخطط لنا؟

لا. تعمل Flyway على خوادمكم وخطوط التسليم لديكم، فتبقى قواعد البيانات والبيانات حيث هي. ويدعم مهندسو إنتركي العملية من الرياض بالعربية والإنجليزية، وينبغي أن تحمل نسخ الاختبار بيانات مقنَّعة أو مولَّدة.

صفحات ذات صلة

الخطوة التالية

راجعوا طريقة ترحيل المخطط لديكم

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

الاسم الأول اسم العائلة

البريد الإلكتروني للشركة اسم الشركة أو الجهة

رقم الجوال (اختياري) قواعد البيانات لديكم وكيف تصل تغييرات المخطط اليوم

خانة إلزامية

بإرسالك هذا النموذج، فأنت توافق على سياسة الخصوصية.

نشرته إنتركي. آخر تحديث 2026-11-10. إنتركي مسجلة في الرياض بالسجل التجاري رقم 1010156897.

التقاط خط الأساس.

اختيار النهج.

تجربة على مخطط واحد.

التدرّب على طريق العودة.

التسليم أو التشغيل.

راجعوا طريقة ترحيل المخطط لديكم