Oracle إلى SQL Server و SQL Server إلى Oracle Migration Guide - Pt. 3

ناقش الجزءان الأول والثاني من هذه السلسلة الاختلافات بين Oracle Database و Microsoft SQL Server في تنفيذها للمعاملات ، ومخاطر التحويل الناتجة ، بالإضافة إلى بعض عناصر البنية الشائعة الاستخدام.

ستغطي هذه الدفعة الأخيرة فكرة تناسق قراءة Oracle وكيفية تحويل البنية ، بناءً على هذه الفكرة ، إلى إصدار Microsoft SQL Server. سيتناول أيضًا استخدام المرادفات (وكيفية عدم استخدامها) ودور عملية التحكم في التغيير في إدارة بيئة قاعدة البيانات الخاصة بك.

تناسق قراءة Oracle وما يعادله في SQL Server

تناسق قراءة Oracle هو ضمان أن جميع البيانات التي يتم إرجاعها بواسطة عبارة SQL واحدة تأتي من نفس النقطة الزمنية الفردية.

هذا يعني أنك إذا أصدرت SELECT في 12:01: 02.345 وتم تشغيلها لمدة 5 دقائق قبل إرجاع مجموعة النتائج ، فإن جميع البيانات (والبيانات فقط) التي تم الالتزام بها في قاعدة البيانات اعتبارًا من 12:01: 02.345 ستجعلها في مجموعة عودتك. لن تحتوي مجموعة الإرجاع الخاصة بك على أي بيانات جديدة مضافة خلال تلك الدقائق الخمس التي استغرقتها قاعدة البيانات لمعالجة البيان الخاص بك ، ولا أي تحديثات ، ولن تظهر أي عمليات حذف.

تحقق بنية Oracle تناسقًا في القراءة عن طريق ختم الوقت داخليًا لكل تغيير في البيانات وإنشاء مجموعة نتائج من مصدرين: ملفات البيانات الدائمة وقطاع التراجع (أو "جزء التراجع" ، كما كان معروفًا حتى الإصدار 10g).

من أجل دعمها ، يجب الحفاظ على معلومات التراجع. إذا تم استبدالها ، فسيؤدي ذلك إلى ظهور خطأ ORA-01555: snapshot too old .

ترك جانب التراجع عن إدارة المقطع - وكيفية التنقل في ORA-01555: snapshot too old - فلنلقِ نظرة على الآثار المترتبة على تناسق القراءة على أي تنفيذ عملي في Oracle. أيضًا ، كيف يجب أن ينعكس في SQL Server ، والذي - كما هو الحال مع تطبيقات RDBMS الأخرى ، مع الاستثناء المحتمل والمؤهل لـ PostgreSQL - لا يدعمه؟

المفتاح هو أن Oracle تقرأ وتكتب لا تمنع بعضها البعض. وهذا يعني أيضًا أن مجموعة إرجاع الاستعلام طويل المدى قد لا تحتوي على أحدث البيانات.

تعد عمليات القراءة والكتابة بدون حظر ميزة تتمتع بها Oracle ، كما أنها تؤثر على نطاق المعاملة.

لكن اتساق القراءة يعني أيضًا أنه ليس لديك أحدث حالة للبيانات. عندما يكون الأمر جيدًا تمامًا في بعض السيناريوهات (مثل إنتاج تقرير لفترة معينة) ، فقد يؤدي ذلك إلى حدوث مشكلات مهمة في حالات أخرى.

قد يكون عدم وجود أحدث البيانات - حتى "القذرة" أو غير الملتزمة - أمرًا بالغ الأهمية: السيناريو الكلاسيكي هو نظام حجز غرفة في الفندق.

ضع في اعتبارك حالة الاستخدام التالية: لديك وكيلان لخدمة العملاء يقبلان في نفس الوقت أوامر حجز الغرف. كيف يمكنك التأكد من عدم زيادة الحجز في الغرف؟

في SQL Server ، يمكنك بدء معاملة SELECT وتحديد سجل من القائمة (التي يمكن أن تكون جدولًا أو طريقة عرض) للغرف المتاحة. طالما لم يتم إغلاق هذه المعاملة (إما عن طريق COMMIT أو ROLLBACK ) ، فلا يمكن لأي شخص الحصول على نفس سجل الغرفة الذي حددته. هذا يمنع الحجز المزدوج ولكنه أيضًا يجعل كل وكيل آخر ينتظر بعضه البعض لإكمال طلبات الحجز واحدًا تلو الآخر ، بالتتابع.

في Oracle ، يمكنك تحقيق نفس النتيجة عن طريق إصدار SELECT ... FOR UPDATE البيان مقابل السجلات المطابقة لمعايير البحث الخاصة بك.

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

الخلاصة : اتساق قراءة Oracle ليس "كل شيء جيدًا" أو "سيئًا بالكامل" ولكنه خاصية مهمة للنظام الأساسي يجب فهمه جيدًا وهو أمر بالغ الأهمية لترحيل التعليمات البرمجية عبر الأنظمة الأساسية.

المرادفات العامة (والخاصة) في Oracle و Microsoft SQL Server

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

في العديد من بيئات قواعد البيانات - أود أن أقول إن جميع بيئات Oracle التي أتيحت لي الفرصة للعمل معها ، ولكن لم أقم بتصميم أي منها - كان استخدام CREATE PUBLIC SYNONYM لكل كائن أمرًا روتينيًا لأننا "لقد فعلنا ذلك دائمًا بهذه الطريقة."

في هذه البيئات ، كان للمرادفات العامة وظيفة واحدة فقط: السماح بالإشارة إلى كائن دون تحديد مالكه. وهذا سبب غير مدروس جيدًا لجعل المرادفات العامة.

ومع ذلك ، يمكن أن تكون مرادفات Oracle العامة مفيدة للغاية وتعطي مزايا إنتاجية الفريق التي تفوق بشكل كبير جميع عيوبها ، إذا تم تنفيذها وإدارتها بشكل صحيح ولسبب ما. نعم ، قلت "إنتاجية الفريق". ولكن كيف؟ لهذا ، نحتاج إلى فهم كيفية عمل تحليل الاسم في Oracle.

عندما يعثر محلل Oracle على اسم (كلمة أساسية غير محجوزة) ، فإنه يحاول مطابقته مع كائن قاعدة بيانات موجود بالترتيب التالي:

ملاحظة: سيكون الخطأ الذي حدث هو ORA-00942: table or view does not exist لعبارات DML ، أو PLS-00201: identifier 'my_object' must be declared للإجراءات المخزنة أو استدعاءات الوظائف.

في ترتيب تحليل الاسم هذا ، من السهل ملاحظة أنه عندما يعمل المطور في مخططه الخاص ، فإن أي كائن محلي يحمل نفس الاسم كمرادف عام سيخفي هذا المرادف العام. (ملاحظة: طبقت Oracle 18c نوع مخطط "تسجيل الدخول فقط" ، ولا تنطبق هذه المناقشة عليه.)

المرادفات العامة لفرق Scaling Teams: Oracle Change Control

دعنا الآن نلقي نظرة على فريق افتراضي مكون من 100 مطور يعملون على نفس قاعدة البيانات (وهو شيء اختبرته). علاوة على ذلك ، لنفترض أنهم جميعًا يعملون محليًا على محطات العمل الشخصية الخاصة بهم ويقومون ببناء غير قاعدة البيانات بشكل مستقل ، وكلها مرتبطة ببيئة تطوير قاعدة البيانات نفسها. سيتم تنفيذ قرار دمج الكود في كود غير متعلق بقاعدة البيانات (سواء كان C # أو Java أو C ++ أو Python أو أي شيء آخر) في وقت تسجيل الوصول للتحكم في التغيير وسيصبح ساريًا مع إنشاء الكود التالي. لكن جداول قاعدة البيانات ، والكود ، والبيانات تحتاج إلى التغيير ذهابًا وإيابًا عدة مرات أثناء التطوير المستمر. يقوم كل مطور بذلك بشكل مستقل ، ويسري على الفور.

لهذا ، يتم إنشاء جميع كائنات قاعدة البيانات في مخطط تطبيق مشترك. هذا هو المخطط الذي يشير إليه التطبيق. كل مطور:

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

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

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

بعد ذلك ، يمكن لفريق التطوير بأكمله رؤية نفس قاعدة البيانات مرة أخرى. يقوم المطور الذي قام للتو بتسليم الكود بإسقاط جميع الكائنات من مخططه الشخصي ويكون جاهزًا لمهمة جديدة.

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

في SQL Server ، يتم تحديد المخطط الافتراضي الحالي للمستخدم في تكوين المستخدم ويمكن تغييره في أي وقت إذا كان لديك امتيازات "تغيير المستخدم". يمكن تنفيذ نفس المنهجية الموضحة أعلاه لنظام Oracle. ومع ذلك ، إذا لم يتم استخدام هذه الطريقة ، فلا ينبغي نسخ المرادفات العامة.

نظرًا لأن Microsoft SQL Server لا يربط حساب مستخدم جديد بالمخطط الخاص به افتراضيًا (كما تفعل Oracle) ، يجب أن يكون الارتباط جزءًا من البرنامج النصي القياسي "إنشاء مستخدم".

يوجد أدناه مثال على برنامج نصي يقوم بإنشاء مخططات مستخدم مخصصة ويعين أحدها للمستخدم.

أولاً ، أنشئ مخططات للمستخدمين الجدد الذين يحتاجون إلى الانضمام إلى قاعدة البيانات المسماة DevelopmentDatabase (يجب إنشاء كل مخطط في دفعته الخاصة):

 use DevelopmentDatabase; GO CREATE SCHEMA Dev1; GO CREATE SCHEMA Dev2; GO

ثانيًا ، أنشئ المستخدم الأول بالمخطط الافتراضي المعين له:

 CREATE LOGIN DevLogin123 WITH PASSWORD = 'first_pass123'; CREATE USER Dev1 FOR LOGIN DevLogin123 WITH DEFAULT_SCHEMA = Dev1; GO

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

بعد ذلك ، قم بإنشاء المستخدم الآخر بدون مخطط افتراضي:

 CREATE LOGIN DevLogin321 WITH PASSWORD = 'second_pass321'; CREATE USER Dev2 FOR LOGIN DevLogin321; GO

مخطط قاعدة البيانات الافتراضي للمستخدم Dev2 هو dbo .

الآن غير المستخدم Dev2 لتغيير مخططه الافتراضي إلى Dev2 :

 ALTER USER Dev2 WITH DEFAULT_SCHEMA = Dev2; GO

الآن مخطط قاعدة البيانات الافتراضي للمستخدم Dev2 هو Dev2 .

يوضح هذا البرنامج النصي طريقتين لتعيين مخطط افتراضي وتغييره لمستخدم في قواعد بيانات Microsoft SQL Server. نظرًا لأن SQL Server يدعم طرقًا متعددة لمصادقة المستخدم (الأكثر شيوعًا هي مصادقة Windows) وقد يتم التعامل مع إعداد المستخدم بواسطة مسؤولي النظام بدلاً من مسؤولي قواعد البيانات ، فإن طريقة ALTER USER لتعيين / تغيير المخطط الافتراضي ستكون أكثر قابلية للاستخدام.

ملاحظة: لقد جعلت اسم المخطط هو نفسه اسم المستخدم. ليس من الضروري أن يكون الأمر بهذه الطريقة في SQL Server ، ولكن هذا هو المفضل لدي لأنه (1) يطابق الطريقة التي يتم إجراؤها في Oracle و (2) يبسط إدارة المستخدم (معالجة أكبر اعتراض من جانب DBA للقيام بذلك بشكل صحيح في المقام الأول) - أنت تعرف اسم المستخدم وتعرف تلقائيًا مخطط قاعدة البيانات الافتراضي للمستخدم.

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

إدارة الوصول إلى قواعد البيانات وعمليات إدارة التغيير

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

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

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

سقسقة

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

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

كل فريق تطوير - وكل من مطوريهم - لديه هدف محدد بشكل خاص للغاية وتسليمات محددة للغاية. الهدف الوحيد الموجود على مكتب DBA كل يوم هو استقرار قاعدة البيانات كمورد مشترك. يلعب DBA دورًا فريدًا في المؤسسة للإشراف على جميع جهود التطوير عبر جميع الفرق والتحكم في قاعدة البيانات التي يصل إليها جميع المطورين. إنه مسؤول قاعدة البيانات الذي يضمن أن جميع المشاريع وجميع العمليات تعمل دون التدخل مع بعضها البعض وأن كل منها لديه الموارد اللازمة للعمل.

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

لا يعرف المطورون ، وليس لديهم وصول ، ولا يهتمون حتى بما يحدث في قاعدة البيانات طالما أنها تعمل بشكل جيد بالنسبة لهم. (إنه ليس منجزاتهم ، ولن يؤثر على تقييم أدائهم.)

يحافظ فريق DBA على قاعدة البيانات قريبة من الصندوق ، ويحميها من المطورين الذين "لا يعرفون شيئًا" عنها ، لأن هدف فريقهم هو استقرار قاعدة البيانات. وأفضل طريقة لضمان الاستقرار هي منع التغييرات المدمرة - مما يؤدي غالبًا إلى موقف لحماية قاعدة البيانات من أي تغييرات قدر الإمكان.

يمكن أن تؤدي هذه المواقف المتضاربة تجاه قاعدة البيانات ، كما رأيت ، إلى العداء بين فرق التطوير وفرق DBA وتؤدي إلى بيئة غير قابلة للعمل. لكن يجب على مسؤولي قواعد البيانات وفريق التطوير العمل معًا لتحقيق هدف مشترك: تقديم حل للأعمال ، وهو ما جمعهم معًا في المقام الأول.

نظرًا لكوني على جانبي تقسيم المطور - DBA ، فأنا أعلم أنه من السهل حل المشكلة عندما يفهم مسؤولو قواعد البيانات المهام والأهداف المشتركة لفرق التطوير بشكل أفضل. من جانبهم ، يحتاج المطورون إلى رؤية قاعدة البيانات ليس كمفهوم مجرد ولكن كمورد مشترك - وهناك ، يجب أن يتولى مسؤول قاعدة البيانات دور المعلم.

الخطأ الأكثر شيوعًا الذي يرتكبه مسؤولو قواعد البيانات (DBA) غير المطورين هو تقييد وصول المطور إلى قاموس البيانات وأدوات تحسين التعليمات البرمجية. يبدو الوصول إلى عروض كتالوج Oracle DBA_ ، وطرق عرض V$ الديناميكية ، وجداول SYS للعديد من مسؤولي قواعد البيانات "يتمتعون بامتياز DBA" عندما تكون في الواقع أدوات تطوير مهمة.

ينطبق الأمر نفسه على SQL Server ، مع تعقيد واحد: لا يمكن منح الوصول إلى بعض طرق عرض النظام مباشرةً ، ومع ذلك فهو جزء فقط من دور قاعدة بيانات SYSADMIN ، ولا ينبغي منح هذا الدور أبدًا خارج فريق DBA. يمكن حل هذا (ويجب حله في حالة ترحيل المشروع من Oracle إلى SQL Server) عن طريق إنشاء طرق عرض وإجراءات مخزنة يتم تنفيذها بموجب امتيازات SYSADMIN ولكن يمكن الوصول إليها من قبل مستخدمي DBA غير. هذه هي مهمة تطوير DBA للقيام بها كبيئة تطوير SQL Server جديدة تم تكوينها.

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

عندما يتم إنشاء علاقات عمل مناسبة بين التطوير وفرق DBA ، يصبح إنشاء عملية جيدة للتحكم في التغيير أمرًا بديهيًا. تتمثل خصوصيات إدارة التغيير من جانب قاعدة البيانات وتحديها في صلابة قاعدة البيانات وسيولتها في نفس الوقت - الهيكل جامد ، والبيانات سائلة.

غالبًا ما يحدث أن تكون إدارة التغيير في تعديل الهيكل - أي لغة تعريف البيانات أو DDL - راسخة في حين أن تغييرات البيانات ليس لها سوى القليل أو لا شيء على الإطلاق في طريقة إدارة التغيير. التبرير بسيط - البيانات تتغير طوال الوقت.

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

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

في Oracle ، يجب أن يتم ذلك عن طريق وضع كل من بيانات المستخدم والتطبيق في مخططها الخاص. في Microsoft SQL Server ، يجب أن يتم ذلك عن طريق وضع كل منها في مخطط منفصل أو - أفضل بكثير - في قاعدة بيانات منفصلة. يجب أن يكون إجراء هذه الاختيارات جزءًا من تخطيط الترحيل: لدى Oracle دقة اسم من مستويين (مخطط / مالك - اسم كائن) بينما يحتوي SQL Server على تحليل اسم ثلاثي المستويات (قاعدة بيانات - مخطط / مالك - اسم كائن).

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

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

حول استخدام أدوات ترحيل التعليمات البرمجية

يمكن أن تكون أدوات الطرف الأول القياسية ، Oracle Migration Workbench و SQL Server Migration Assistant مفيدة في عمليات ترحيل التعليمات البرمجية. ولكن ما يجب مراعاته هو قاعدة 80/20: عندما يتم ترحيل الرمز بنسبة 80٪ بشكل صحيح ، فإن حل نسبة 20٪ المتبقية سيستغرق 80٪ من جهد الترحيل الخاص بك.

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

من ناحية أخرى ، استغرق الأمر أربعة أيام عمل لإنجاز التحويل الأساسي لنظام Microsoft SQL Server 2008 متوسط ​​الحجم (حوالي 200 عنصر) باستخدام وظيفة الاستبدال المجمع في Notepad ++ كأداة التحرير الرئيسية.

لا يمكن حل أي من عناصر الترحيل الهامة التي تناولتها حتى الآن بواسطة أدوات الترحيل.

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

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

الخلاصة : يعد استخدام أدوات المساعدة في الترحيل مفيدًا ولكنه ليس "حل سحري" ، ولا يزال أي مشروع تحويل يتطلب مراجعة تفصيلية للنقاط المذكورة أعلاه.

عمليات ترحيل خادم Oracle / SQL: ألق نظرة عن كثب دائمًا

Oracle و Microsoft SQL Server هما أكثر منصات RDBMS انتشارًا في بيئة المؤسسة. كلاهما له امتثال أساسي لمعيار ANSI SQL ، ويمكن نقل أجزاء صغيرة من التعليمات البرمجية مع القليل من التعديل ، أو حتى كما هي.

يخلق هذا التشابه انطباعًا خادعًا بأن الترحيل عبر النظامين الأساسيين هو مهمة بسيطة ومباشرة وأنه يمكن بسهولة اعتماد التطبيق نفسه من استخدام طرف خلفي RDBMS إلى آخر.

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

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